* Re: [PATCH] rtlwifi: Add updates for RTL8723BE and RTL8821AE
From: Kyle McMartin @ 2016-11-28 16:24 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, netdev, linux-firmware
In-Reply-To: <20161127192834.19907-1-Larry.Finger@lwfinger.net>
On Sun, Nov 27, 2016 at 01:28:34PM -0600, Larry Finger wrote:
> The new versions will only work with new versions of the drivers. For
> that reason, they are given new names and the old versions are retained.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 4 ++++
applied, thanks Larry.
regards, --kyle
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Ulf Hansson @ 2016-11-28 15:54 UTC (permalink / raw)
To: Rob Herring
Cc: Matt Ranostay, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-mmc@vger.kernel.org, Tony Lindgren, Mark Rutland,
Srinivas Kandagatla
In-Reply-To: <20161128141513.agnkyz6ronigbukn@rob-hp-laptop>
[...]
>> +
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>> + }
>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>> so that the wifi chip can wakeup host platform under certain condition.
>> during system resume, the irq will be disabled to make sure
>> unnecessary interrupt is not received.
>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>
> This is why pwrseq is wrong. You have some properties in the card node
> and some in pwrseq node. Everything should be in the card node.
Put "all" in the card node, just doesn't work for MMC. Particular in
cases when we have removable cards, as then it would be wrong to have
a card node.
The mmc pwrseq DT bindings just follows the legacy approach for MMC
and that's why the pwrseq handle is at the controller node. Yes, would
could have done it differently, but this is the case now, so we will
have to accept that.
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: rtl8xxxu: tx rate reported before set
From: Kalle Valo @ 2016-11-28 15:37 UTC (permalink / raw)
To: Barry Day; +Cc: Jes Sorensen, linux-wireless
In-Reply-To: <20161126021158.GA12838@box64.home.org>
Barry Day <briselec@gmail.com> wrote:
> Move the dev_info call that attempts to show the rate used before it is set.
>
> Signed-off-by: Barry Day <briselec@gmail.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Barry Day <briselec@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
c06696a95820 rtl8xxxu: tx rate reported before set
--
https://patchwork.kernel.org/patch/9448225/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/3][RFC] nl80211/mac80211: Accept multiple RSSI thresholds for CQM
From: Johannes Berg @ 2016-11-28 15:35 UTC (permalink / raw)
To: Andrew Zaborowski; +Cc: linux-wireless
In-Reply-To: <CAOq732LFeKRjPdQ6xMx_d1cHmQmYp50NJ4MDsdf=mPXMs685PQ@mail.gmail.com>
On Mon, 2016-11-28 at 16:29 +0100, Andrew Zaborowski wrote:
> In order to keep the hardware offload feature when working with
> hardware that can only offload the old single-thresholds method, but
> where the kernel also wants to support the new method by looking at
> all the beacons in software. IIRC I identified just one driver that
> would be in this situation: wl1271.
IMHO it would be better to not allow that. I'd think that wl1271 is
only used in devices where power consumption will be far more
interesting than providing this kind of API.
> This is a specific case and the semantics implemented by the wl1271
> may be a little different from those in the rest of the drivers so
> this may be worth very little. I can change the comment to imply
> only one method should be implemented.
We might still have to allow both to be present for mac80211 though.
> > Seems there still should be a hysteresis? Or am I misunderstanding
> > the
> > intent here? I.e. isn't it meant to report low/medium/high later?
>
> This isn't exposed directly to users, instead it's used by the code
> in
> nl80211.c which will always reset the thresholds when either
> threshold
> is crossed. The hysteresis can then be either handled in nl80211.c
> (factored into the threshold values) or in the firmware/driver, this
> won't change the number of wakeups.
That's only if you assume you can actually react to this fast enough
though, no? If I offload this, I'd want to also offload a hysteresis to
firmware, I'd think.
johannes
^ permalink raw reply
* Re: [PATCH] ath9k_htc: don't use HZ for usb msg timeouts
From: Oleksij Rempel @ 2016-11-28 15:34 UTC (permalink / raw)
To: Anthony Romano, linux-wireless, ath9k-devel; +Cc: ath9k-devel
In-Reply-To: <20161128042757.8609-1-anthony.romano@coreos.com>
[-- Attachment #1.1: Type: text/plain, Size: 2887 bytes --]
Hi Anthony,
Am 28.11.2016 um 05:27 schrieb Anthony Romano:
> The usb_*_msg() functions expect a timeout in msecs but are given HZ,
> which is ticks per second. If HZ=100, firmware download often times out
> when there is modest USB utilization and the device fails to initialize.
> Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
> for timeouts in jiffies.
wow..
This fix allow you use 4 adapter at same time?
> Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 9 +++++----
> drivers/net/wireless/ath/ath9k/hif_usb.h | 2 ++
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index e1c338cb9cb5..de2d212f39ec 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -997,7 +997,8 @@ static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
> err = usb_control_msg(hif_dev->udev,
> usb_sndctrlpipe(hif_dev->udev, 0),
> FIRMWARE_DOWNLOAD, 0x40 | USB_DIR_OUT,
> - addr >> 8, 0, buf, transfer, HZ);
> + addr >> 8, 0, buf, transfer,
> + USB_MSG_TIMEOUT);
> if (err < 0) {
> kfree(buf);
> return err;
> @@ -1020,7 +1021,7 @@ static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
> err = usb_control_msg(hif_dev->udev, usb_sndctrlpipe(hif_dev->udev, 0),
> FIRMWARE_DOWNLOAD_COMP,
> 0x40 | USB_DIR_OUT,
> - firm_offset >> 8, 0, NULL, 0, HZ);
> + firm_offset >> 8, 0, NULL, 0, USB_MSG_TIMEOUT);
> if (err)
> return -EIO;
>
> @@ -1249,7 +1250,7 @@ static int send_eject_command(struct usb_interface *interface)
>
> dev_info(&udev->dev, "Ejecting storage device...\n");
> r = usb_bulk_msg(udev, usb_sndbulkpipe(udev, bulk_out_ep),
> - cmd, 31, NULL, 2000);
> + cmd, 31, NULL, 2 * USB_MSG_TIMEOUT);
> kfree(cmd);
> if (r)
> return r;
> @@ -1314,7 +1315,7 @@ static void ath9k_hif_usb_reboot(struct usb_device *udev)
> return;
>
> ret = usb_interrupt_msg(udev, usb_sndintpipe(udev, USB_REG_OUT_PIPE),
> - buf, 4, NULL, HZ);
> + buf, 4, NULL, USB_MSG_TIMEOUT);
> if (ret)
> dev_err(&udev->dev, "ath9k_htc: USB reboot failed\n");
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.h b/drivers/net/wireless/ath/ath9k/hif_usb.h
> index 7c2ef7ecd98b..7846916aa01d 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.h
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
> @@ -71,6 +71,8 @@ extern int htc_use_dev_fw;
> #define USB_REG_IN_PIPE 3
> #define USB_REG_OUT_PIPE 4
>
> +#define USB_MSG_TIMEOUT 1000 /* (ms) */
> +
> #define HIF_USB_MAX_RXPIPES 2
> #define HIF_USB_MAX_TXPIPES 4
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3][RFC] nl80211/mac80211: Accept multiple RSSI thresholds for CQM
From: Andrew Zaborowski @ 2016-11-28 15:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1480344479.8107.60.camel@sipsolutions.net>
Hi Johannes,
On 28 November 2016 at 15:47, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> + * @set_cqm_rssi_range_config: Configure two RSSI thresholds in the
>> > + * connection quality monitor. Even if the driver implements both the
>> > + * single threshold and low/high thresholds mechanisms, it should assume
>> + * only one is active at any time.
>
> Why would a driver still (be allowed to!) implement both?
In order to keep the hardware offload feature when working with
hardware that can only offload the old single-thresholds method, but
where the kernel also wants to support the new method by looking at
all the beacons in software. IIRC I identified just one driver that
would be in this situation: wl1271.
This is a specific case and the semantics implemented by the wl1271
may be a little different from those in the rest of the drivers so
this may be worth very little. I can change the comment to imply only
one method should be implemented.
>
>> + int (*set_cqm_rssi_range_config)(struct wiphy *wiphy,
>> + struct net_device *dev,
>> + s32 rssi_low, s32 rssi_high);
>
> Seems there still should be a hysteresis? Or am I misunderstanding the
> intent here? I.e. isn't it meant to report low/medium/high later?
This isn't exposed directly to users, instead it's used by the code in
nl80211.c which will always reset the thresholds when either threshold
is crossed. The hysteresis can then be either handled in nl80211.c
(factored into the threshold values) or in the firmware/driver, this
won't change the number of wakeups.
It's probably easier to do it in one place and keep it simple on the drivers?
>
>> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>> index 33026e1..7da1056 100644
>> --- a/include/net/mac80211.h
>> +++ b/include/net/mac80211.h
>
> I'd prefer you split cfg80211 and mac80211 patches, i.e. provide the
> new API first and then implement it in mac80211 separately.
Yes, will do, only as this is purely an RFC I preferred to keep the
conext together.
>
>> +void cfg80211_cqm_config_free(struct wireless_dev *wdev)
>> +{
>> + if (!wdev->cqm_config)
>> + return;
>> +
>> + kfree(wdev->cqm_config->rssi_thresholds);
>> + kfree(wdev->cqm_config);
>> + wdev->cqm_config = NULL;
>> +}
>
> You can save this complexity by just making the cqm_config struct have
> all the thresholds inside itself - pretty easy to allocate by just
> counting them first.
Ok, guess I can do that and let last_rssi_event_value get reset when
the thresholds are reconfigured.
Best regards
^ permalink raw reply
* limiting times ath9k_htc devices are loaded
From: bruce m beach @ 2016-11-28 15:19 UTC (permalink / raw)
To: linux-wireless
Hello
When I plug in a ath9k_htc device, with a loaded driver, the driver
attemps to attach itself to the device and load firmware etc. ( of
course ). Does anyone know how I can tell the driver ( or kernel ) to
do this process only once, and ignore additional insertions of
ath9k_htc devices ?
Bruce
^ permalink raw reply
* Re: Break-it testing for wifi
From: Ben Greear @ 2016-11-28 15:14 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <1480343339.8107.49.camel@sipsolutions.net>
On 11/28/2016 06:28 AM, Johannes Berg wrote:
> On Tue, 2016-11-22 at 08:59 -0800, Ben Greear wrote:
>>> Why would you do that? In order to test the AP implementation?
>>
>> Yes. And really, you should be able to do similar things on the AP
>> to test stations, or on IBSS/Mesh devices, etc. hostapd already has
>> some options to corrupt or drop a percentage of various management
>> frames. Supplicant does not as far as I know.
>
> Yes, but that's a far different focus. I'm far more interested in
> testing *our* implementation(s), at which point I don't need to do it
> over the air for most cases, and can be much more efficient that way,
> etc.
>
> I also don't really see a point of doing anything over the air to test
> our implementations, apart from hitting firmware (but even then ...)
OTA is of primary importance to me, but I think any solution that works
for OTA would work for hwsim as well.
>
>>>> 2) Randomly corrupt mgt frames in driver and/or mac80211 stack
>>>> and/or supplicant.
>>>
>>> I think fuzzing the input path for those frames would be more
>>> useful than just corrupting things.
>>
>> Random corruptions, especially by code that had at least some
>> understanding of management frames should be fast and easy to
>> use. It would not be as good as a really clever fuzzer or hand-
>> crafted frames, but for many users, hand-crafting attacks would be
>> well beyond what they could ever accomplish.
>
> Define "user"?
System-test engineer in random company. Like most of us, I am not working
for pure charity purposes :)
>
>> Currently, supplicant can (at least with some small patches that I
>> carry), add custom information elements to probe requests and
>> similar. But, some things are built by mac80211 (rate-sets
>> advertised, for instance). So, I was thinking of slightly extending
>> the API so that user-space could over-ride whatever mac80211 might
>> normally build itself. That lets you more properly fuzz things from
>> user space.
>
> Why bother though, at that point? If you hook up some state transitions
> you can probably just send the frames from userspace. For these testing
> scenarios you can make assumptions about the hardware or query it
> beforehand, so there's no need to rely on mac80211 at all?
I don't want to re-implement supplicant, nor heavily modify it for this
effort. I'm not sure exactly how important modifying IEs from user-space
would be for my effort, maybe existing API is enough with in-kernel fuzzer
I am thinking about writing.
>
>> Yes, but for ease of use, and to cover frames generated by mac80211,
>> I was thinking:
>>
>> echo 0.25 > /debug/.../wlan0/mgt_fuzzer
>>
>> The fuzzer would then corrupt 25% of the management frames. And
>> instead of just randomly scribbling, it could also parse the frames
>> and do some more clever (and still pseudo-random) modifications to
>> the frames, like re-writing IEs with bad lengths, flipping bits in
>> specific portions of the frame we feel might find problems, etc.
>>
>> I think if the tool became useful, then it could grow more clever
>> over time.
>
> I'd be far more inclined to just add a tracepoint there at some spot
> and allow attaching BPF programs to it ... Or perhaps allow attaching
> BPF programs directly, if tracepoint BPF can't modify the data.
>
> Having any kind of logic here in the kernel space seems fairly useless
> since you'll want to change it often, etc.
Well, in-kernel seems best to me. I will give it a try and see how
it works.
Thanks,
Ben
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: cfg80211: add set/get link loss profile
From: Johannes Berg @ 2016-11-28 14:52 UTC (permalink / raw)
To: Lazar, Alexei Avshalom; +Cc: linux-wireless
In-Reply-To: <7742335b-f05e-edcd-ad80-fd09fb295eab@codeaurora.org>
> Introduce NL80211_CMD_SET_LINK_LOSS_PROFILE and
> NL80211_CMD_GET_LINK_LOSS_PROFILE as it required by the user space
> to configure the link loss profile.
I'm not convinced.
> The link loss profile represents the priority of maintaining link up
> in different link quality environments.
> Three types of behavior for link loss defined:
> LINK_LOSS_PROFILE_RELAXED: prefer maintaining link up even in poor
> link quality environment.
> LINK_LOSS_PROFILE_DEFAULT: The default behavior for maintaining link
> up vs link quality.
> LINK_LOSS_PROFILE_AGGRESSIVE: prefer losing link up in poor link
> quality environment.
What you're doing here is *extremely* vague. No definitions of what
this means, no description of how it's intended to be implemented, no
note even on whether or not this is for full-MAC chips or not, etc.
At least for mac80211, we can define signals to userspace regarding
"link quality" and make decisions in wpa_s then?
> --- a/drivers/net/wireless/ath/wil6210/cfg80211.c
Those changes obviously don't belong into this patch anyway.
johannes
^ permalink raw reply
* Re: [PATCH 3/3][RFC] nl80211/mac80211: Accept multiple RSSI thresholds for CQM
From: Johannes Berg @ 2016-11-28 14:47 UTC (permalink / raw)
To: Andrew Zaborowski, linux-wireless
In-Reply-To: <1478398113-14966-4-git-send-email-andrew.zaborowski@intel.com>
> + * @set_cqm_rssi_range_config: Configure two RSSI thresholds in the
> > + * connection quality monitor. Even if the driver implements both the
> > + * single threshold and low/high thresholds mechanisms, it should assume
> + * only one is active at any time.
Why would a driver still (be allowed to!) implement both?
> + int (*set_cqm_rssi_range_config)(struct wiphy *wiphy,
> + struct net_device *dev,
> + s32 rssi_low, s32 rssi_high);
Seems there still should be a hysteresis? Or am I misunderstanding the
intent here? I.e. isn't it meant to report low/medium/high later?
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 33026e1..7da1056 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
I'd prefer you split cfg80211 and mac80211 patches, i.e. provide the
new API first and then implement it in mac80211 separately.
> +void cfg80211_cqm_config_free(struct wireless_dev *wdev)
> +{
> + if (!wdev->cqm_config)
> + return;
> +
> + kfree(wdev->cqm_config->rssi_thresholds);
> + kfree(wdev->cqm_config);
> + wdev->cqm_config = NULL;
> +}
You can save this complexity by just making the cqm_config struct have
all the thresholds inside itself - pretty easy to allocate by just
counting them first.
johannes
^ permalink raw reply
* Re: [RFC V2 4/5] nl80211: add support for gscan
From: Johannes Berg @ 2016-11-28 14:38 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1479388726-3288-5-git-send-email-arend.vanspriel@broadcom.com>
> * the nl80211 feature flags for the device.
> + * @NL80211_SCAN_FLAGS_IE_DATA: request the device to supply IE data
> in the
> + * request.
What does that mean?
> + * @NL80211_GSCAN_CHAN_ATTR_NO_IR: scanning should be done passive.
why not call that passive? No-IR is something we use in regulatory code
to be more generic than "passive" (since it's also about beaconing
etc.) but here?
> + * @NL80211_GSCAN_CHAN_ATTR_MAX: highest GScan channel attribute.
Generally, you should also document the attribute types here (and
everywhere else really)
> + NL80211_BUCKET_BAND_2GHZ = (1 << 0),
no need for parentheses with enums :)
> + if (tb[NL80211_GSCAN_CHAN_ATTR_DWELL_TIME])
> + chan->dwell_time =
> nla_get_u32(tb[NL80211_GSCAN_CHAN_ATTR_DWELL_TIME]);
Maybe that should have some kind of "reasonable range" limit?
So I mostly looked at this from a pure code POV - need to compare with
our implementation, but I guess the basis is the same ...
johannes
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Luca Coelho @ 2016-11-28 14:34 UTC (permalink / raw)
To: Johannes Berg, Arend Van Spriel, Jouni Malinen
Cc: linux-wireless, vamsi krishna
In-Reply-To: <1480342821.8107.44.camel@sipsolutions.net>
On Mon, 2016-11-28 at 15:20 +0100, Johannes Berg wrote:
> > It seems there has already
> > been taken a shot at this which may be used/extended [1].
> >
>
> That's a good point - it's somewhat similar.
>
> This is obviously a different context - offloaded BSS selection vs.
> scheduled scan (for host BSS selection), but perhaps the attribute &
> definitions could be reused?
Yes, similar but not quite the same. The existing case is for finding
BSSs that are worth waking the host up for (while disconnected), so it
needs to be better than the RSSI passed (absolute number). Now this is
about relative RSSI as compared to the current connection, so
RELATIVE_RSSI is different than RSSI and I think the same attribute
should not be used, to avoid confusion.
--
Luca.
^ permalink raw reply
* Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results
From: Johannes Berg @ 2016-11-28 14:32 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1479388726-3288-2-git-send-email-arend.vanspriel@broadcom.com>
> + * @distance: distance to AP with %parent_bssid in centimeters. Zero
> + * value indicates this is undetermined.
> + * @var_distance: variance of %distance indicating accurracy.
accuracy
The distance between the two APs? Where are you even obtaining that
information from?
johannes
^ permalink raw reply
* Re: Break-it testing for wifi
From: Johannes Berg @ 2016-11-28 14:28 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org
In-Reply-To: <5834797B.2090805@candelatech.com>
On Tue, 2016-11-22 at 08:59 -0800, Ben Greear wrote:
> > Why would you do that? In order to test the AP implementation?
>
> Yes. And really, you should be able to do similar things on the AP
> to test stations, or on IBSS/Mesh devices, etc. hostapd already has
> some options to corrupt or drop a percentage of various management
> frames. Supplicant does not as far as I know.
Yes, but that's a far different focus. I'm far more interested in
testing *our* implementation(s), at which point I don't need to do it
over the air for most cases, and can be much more efficient that way,
etc.
I also don't really see a point of doing anything over the air to test
our implementations, apart from hitting firmware (but even then ...)
> > > 2) Randomly corrupt mgt frames in driver and/or mac80211 stack
> > > and/or supplicant.
> >
> > I think fuzzing the input path for those frames would be more
> > useful than just corrupting things.
>
> Random corruptions, especially by code that had at least some
> understanding of management frames should be fast and easy to
> use. It would not be as good as a really clever fuzzer or hand-
> crafted frames, but for many users, hand-crafting attacks would be
> well beyond what they could ever accomplish.
Define "user"?
> Currently, supplicant can (at least with some small patches that I
> carry), add custom information elements to probe requests and
> similar. But, some things are built by mac80211 (rate-sets
> advertised, for instance). So, I was thinking of slightly extending
> the API so that user-space could over-ride whatever mac80211 might
> normally build itself. That lets you more properly fuzz things from
> user space.
Why bother though, at that point? If you hook up some state transitions
you can probably just send the frames from userspace. For these testing
scenarios you can make assumptions about the hardware or query it
beforehand, so there's no need to rely on mac80211 at all?
> Yes, but for ease of use, and to cover frames generated by mac80211,
> I was thinking:
>
> echo 0.25 > /debug/.../wlan0/mgt_fuzzer
>
> The fuzzer would then corrupt 25% of the management frames. And
> instead of just randomly scribbling, it could also parse the frames
> and do some more clever (and still pseudo-random) modifications to
> the frames, like re-writing IEs with bad lengths, flipping bits in
> specific portions of the frame we feel might find problems, etc.
>
> I think if the tool became useful, then it could grow more clever
> over time.
I'd be far more inclined to just add a tracepoint there at some spot
and allow attaching BPF programs to it ... Or perhaps allow attaching
BPF programs directly, if tracepoint BPF can't modify the data.
Having any kind of logic here in the kernel space seems fairly useless
since you'll want to change it often, etc.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Johannes Berg @ 2016-11-28 14:20 UTC (permalink / raw)
To: Arend Van Spriel, Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <ee0072cd-83b8-1264-d792-bcf4ce1a8940@broadcom.com>
> It seems there has already
> been taken a shot at this which may be used/extended [1].
>
That's a good point - it's somewhat similar.
This is obviously a different context - offloaded BSS selection vs.
scheduled scan (for host BSS selection), but perhaps the attribute &
definitions could be reused?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Johannes Berg @ 2016-11-28 14:17 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1479938857-1788-2-git-send-email-jouni@qca.qualcomm.com>
On Thu, 2016-11-24 at 00:07 +0200, Jouni Malinen wrote:
>
> + int bbr;
bbr? Also, bool?
johannes
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Rob Herring @ 2016-11-28 14:15 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-wireless, linux-kernel, devicetree, linux-mmc,
Tony Lindgren, Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <1479434109-8745-1-git-send-email-matt@ranostay.consulting>
On Thu, Nov 17, 2016 at 05:55:09PM -0800, Matt Ranostay wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
I don't like the MMC pwrseq bindings, so I won't be acking any. Look at
the USB pwrseq for why.
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
> drivers/mmc/core/Kconfig | 10 ++
> drivers/mmc/core/Makefile | 1 +
> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
> 5 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> new file mode 100644
> index 000000000000..1b658351629b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> @@ -0,0 +1,14 @@
> +* Marvell SD8787 power sequence provider
> +
> +Required properties:
> +- compatible: must be "mmc-pwrseq-sd8787".
> +- pwndn-gpio: contains a power down GPIO specifier.
powerdown-gpios
> +- reset-gpio: contains a reset GPIO specifier.
reset-gpios
> +
> +Example:
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-sd8787";
> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
> + }
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> index c421aba0a5bc..08fd65d35725 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -32,6 +32,9 @@ Optional properties:
> so that the wifi chip can wakeup host platform under certain condition.
> during system resume, the irq will be disabled to make sure
> unnecessary interrupt is not received.
> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
This is why pwrseq is wrong. You have some properties in the card node
and some in pwrseq node. Everything should be in the card node.
> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
> + for documentation of MMC power sequence bindings.
>
> Example:
>
> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
> &mmc3 {
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req
From: Johannes Berg @ 2016-11-28 14:14 UTC (permalink / raw)
To: Luca Coelho, Jouni Malinen; +Cc: linux-wireless, Vamsi Krishna
In-Reply-To: <1480063462.2517.105.camel@coelho.fi>
> > + * @NL80211_ATTR_BSSID: The BSSID of the AP (various uses). Note
> > that
>
> The BSSID may also be used for other things, like P2P GO, right? Also
> "various uses" is probably unnecessary? Every command using this
> attribute should describe it's use in their description.
>
>
> >
> > + * %NL80211_ATTR_MAC has also been used in various
> > commands/events for
> > + * specifying the BSSID.
>
> This can be a bit confusing. Maybe you can specify which commands
> *used* to use NL80211_ATTR_MAC but now use NL80211_ATTR_BSSID?
I'd actually avoid that, let's not make the "compatibility quirks" part
of the documentation people read through normally ... In the code,
that's fine, but here, I think less so.
With that, perhaps just rephrase this to
"The BSSID of the AP. Note that %NL80211_ATTR_MAC is also used in
various commands/events for specifying the BSSID."
> > - if (info->attrs[NL80211_ATTR_MAC])
> > + /* Initial implementation used NL80211_ATTR_MAC to set the
> > specific
> > + * BSSID to scan for. This was problematic because that
> > same attribute
> > + * was already used for another purpose (local random MAC
> > address). The
> > + * NL80211_ATTR_BSSID attribute was added to fix this. For
> > backwards
> > + * compatibility with older userspace components, also use
> > the
> > + * NL80211_ATTR_MAC value here if it can be determined to
> > be used for
> > + * the specific BSSID use case instead of the random MAC
> > address
> > + * (NL80211_ATTR_SCAN_FLAGS is used to enable random MAC
> > address use).
> > + */
>
> You should probably add this information to the
> NL80211_CMD_TRIGGER_SCAN description.
It may need an update to refer to ATTR_BSSID, but again I don't think
all the compatibility discussion should be there.
>
> >
> > + if (info->attrs[NL80211_ATTR_BSSID])
> > + memcpy(request->bssid,
> > + nla_data(info->attrs[NL80211_ATTR_BSSID]),
> > ETH_ALEN);
> > + else if (!info->attrs[NL80211_ATTR_SCAN_FLAGS] &&
>
> You should actually check that the SCAN_FLAGS attribute either
> doesn't
> exist (as you already do) or, if it exists, that it doesn't have the
> NL80211_SCAN_FLAG_RANDOM_ADDR flags.
>
Agree with that, that would make sense.
johannes
^ permalink raw reply
* Re: [PATCH 0/4] Fix -Wunused-but-set-variable in net/mac80211/
From: Johannes Berg @ 2016-11-28 13:15 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika@chromium.org>
On Wed, 2016-11-23 at 20:45 -0800, Kirtika Ruchandani wrote:
> This patchset is part of the effort led by Arnd Bergmann to clean up
> warnings in the kernel. This and following patchsets will focus on
> "-Wunused-but-set-variable" as it among the noisier ones. These were
> found compiling with W=1.
All four applied, thanks.
johannes
^ permalink raw reply
* wireless-drivers-next soon closing for 4.10
From: Kalle Valo @ 2016-11-28 12:57 UTC (permalink / raw)
To: linux-wireless
Linus said that he will release 4.9 either next Sunday or a week after,
which means that the merge window is getting close. If there's something
you absolutely need to have in 4.10 better send them NOW to not miss the
window.
Important bug fixes can go to 4.10 also after the merge window, but not
new features.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: build warning after merge of the wireless-drivers-next tree
From: Jes Sorensen @ 2016-11-28 12:26 UTC (permalink / raw)
To: Kalle Valo
Cc: Barry Day, Stephen Rothwell, Wireless, linux-next, linux-kernel
In-Reply-To: <87oa0zygk7.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Barry Day <briselec@gmail.com> writes:
>
>> On Mon, Nov 28, 2016 at 09:25:30AM +0200, Kalle Valo wrote:
>>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>>>
>>> > Hi all,
>>> >
>>> > After merging the wireless-drivers-next tree, today's linux-next build
>>> > (x86_64 allmodconfig) produced this warning:
>>> >
>>> > In file included from include/linux/usb/ch9.h:35:0,
>>> > from include/linux/usb.h:5,
>>> > from drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:32:
>>> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function 'rtl8xxxu_fill_txdesc_v2':
>>> > include/linux/device.h:1214:36: warning: 'rate' may be used uninitialized in this function [-Wmaybe-uninitialized]
>>> > #define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
>>> > ^
>>> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4841:6: note: 'rate' was declared here
>>> > u32 rate;
>>> > ^
>>> >
>>> > Introduced by commit
>>> >
>>> > b4c3d9cfb607 ("rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count")
>>> >
>>> > This is a correct diagnosis.
>>>
>>> Thanks for the report. Jes, can you send a patch to fix this? (Unless
>>> someone else beats to it.)
>>>
>>> --
>>> Kalle Valo
>>
>> I posted a patch on the 26th that fixes this
>
> Thanks, I see it:
>
> https://patchwork.kernel.org/patch/9448225/
>
> The commit log doesn't mention anything about the compilation warning,
> I'll add that. Also a Fixes line is nice to have.
I'm happy with this fix
Acked-by: Jes Sorensen <Jes.Sorensen@redhat.com>
^ permalink raw reply
* Re: rtl8xxxu: tx rate reported before set
From: Jes Sorensen @ 2016-11-28 12:24 UTC (permalink / raw)
To: Kalle Valo; +Cc: Barry Day, linux-wireless
In-Reply-To: <20161128115312.5FE3B6114D@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Barry Day <briselec@gmail.com> wrote:
>> Move the dev_info call that attempts to show the rate used before it is set.
>>
>> Signed-off-by: Barry Day <briselec@gmail.com>
>
> Jes, I would like to take this directly to fix the compiler warning. Also I'll
> change the commit log to:
Kalle,
I'm totally fine with this, please go ahead.
Barry thanks for fixing this.
Cheers,
Jes
> rtl8xxxu: tx rate reported before set
>
> Move the dev_info call that attempts to show the rate used before it is set.
> Fixes a compiler warning:
>
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function
> 'rtl8xxxu_fill_txdesc_v2':
> include/linux/device.h:1214:36: warning: 'rate' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> #define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
>
> Fixes: b4c3d9cfb607 ("rtl8xxxu: Pass tx_info to fill_txdesc in order
> to have access to retry count")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Barry Day <briselec@gmail.com>
^ permalink raw reply
* Re: rtl8xxxu: tx rate reported before set
From: Kalle Valo @ 2016-11-28 11:53 UTC (permalink / raw)
To: Barry Day; +Cc: Jes Sorensen, linux-wireless
In-Reply-To: <20161126021158.GA12838@box64.home.org>
Barry Day <briselec@gmail.com> wrote:
> Move the dev_info call that attempts to show the rate used before it is set.
>
> Signed-off-by: Barry Day <briselec@gmail.com>
Jes, I would like to take this directly to fix the compiler warning. Also I'll
change the commit log to:
rtl8xxxu: tx rate reported before set
Move the dev_info call that attempts to show the rate used before it is set.
Fixes a compiler warning:
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function 'rtl8xxxu_fill_txdesc_v2':
include/linux/device.h:1214:36: warning: 'rate' may be used uninitialized in this function [-Wmaybe-uninitialized]
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
Fixes: b4c3d9cfb607 ("rtl8xxxu: Pass tx_info to fill_txdesc in order to have access to retry count")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Barry Day <briselec@gmail.com>
--
https://patchwork.kernel.org/patch/9448225/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 4/4] wil6210: align to latest auto generated wmi.h
From: Maya Erez @ 2016-11-28 11:49 UTC (permalink / raw)
To: Kalle Valo; +Cc: Lior David, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1480333743-7306-1-git-send-email-qca_merez@qca.qualcomm.com>
From: Lior David <qca_liord@qca.qualcomm.com>
Align to latest version of the auto generated wmi file
describing the interface with FW.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/wmi.h | 392 ++++++++++++++++++++++-----------
1 file changed, 264 insertions(+), 128 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/wmi.h b/drivers/net/wireless/ath/wil6210/wmi.h
index 2cc7775..d93a4d4 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.h
+++ b/drivers/net/wireless/ath/wil6210/wmi.h
@@ -35,6 +35,7 @@
#define WMI_MAC_LEN (6)
#define WMI_PROX_RANGE_NUM (3)
#define WMI_MAX_LOSS_DMG_BEACONS (20)
+#define MAX_NUM_OF_SECTORS (128)
/* Mailbox interface
* used for commands and events
@@ -68,144 +69,149 @@ struct wmi_cmd_hdr {
/* List of Commands */
enum wmi_command_id {
- WMI_CONNECT_CMDID = 0x01,
- WMI_DISCONNECT_CMDID = 0x03,
- WMI_DISCONNECT_STA_CMDID = 0x04,
- WMI_START_SCAN_CMDID = 0x07,
- WMI_SET_BSS_FILTER_CMDID = 0x09,
- WMI_SET_PROBED_SSID_CMDID = 0x0A,
- WMI_SET_LISTEN_INT_CMDID = 0x0B,
- WMI_BCON_CTRL_CMDID = 0x0F,
- WMI_ADD_CIPHER_KEY_CMDID = 0x16,
- WMI_DELETE_CIPHER_KEY_CMDID = 0x17,
- WMI_PCP_CONF_CMDID = 0x18,
- WMI_SET_APPIE_CMDID = 0x3F,
- WMI_SET_WSC_STATUS_CMDID = 0x41,
- WMI_PXMT_RANGE_CFG_CMDID = 0x42,
- WMI_PXMT_SNR2_RANGE_CFG_CMDID = 0x43,
- WMI_MEM_READ_CMDID = 0x800,
- WMI_MEM_WR_CMDID = 0x801,
- WMI_ECHO_CMDID = 0x803,
- WMI_DEEP_ECHO_CMDID = 0x804,
- WMI_CONFIG_MAC_CMDID = 0x805,
- WMI_CONFIG_PHY_DEBUG_CMDID = 0x806,
- WMI_ADD_DEBUG_TX_PCKT_CMDID = 0x808,
- WMI_PHY_GET_STATISTICS_CMDID = 0x809,
- WMI_FS_TUNE_CMDID = 0x80A,
- WMI_CORR_MEASURE_CMDID = 0x80B,
- WMI_READ_RSSI_CMDID = 0x80C,
- WMI_TEMP_SENSE_CMDID = 0x80E,
- WMI_DC_CALIB_CMDID = 0x80F,
- WMI_SEND_TONE_CMDID = 0x810,
- WMI_IQ_TX_CALIB_CMDID = 0x811,
- WMI_IQ_RX_CALIB_CMDID = 0x812,
- WMI_SET_UCODE_IDLE_CMDID = 0x813,
- WMI_SET_WORK_MODE_CMDID = 0x815,
- WMI_LO_LEAKAGE_CALIB_CMDID = 0x816,
- WMI_MARLON_R_READ_CMDID = 0x818,
- WMI_MARLON_R_WRITE_CMDID = 0x819,
- WMI_MARLON_R_TXRX_SEL_CMDID = 0x81A,
- MAC_IO_STATIC_PARAMS_CMDID = 0x81B,
- MAC_IO_DYNAMIC_PARAMS_CMDID = 0x81C,
- WMI_SILENT_RSSI_CALIB_CMDID = 0x81D,
- WMI_RF_RX_TEST_CMDID = 0x81E,
- WMI_CFG_RX_CHAIN_CMDID = 0x820,
- WMI_VRING_CFG_CMDID = 0x821,
- WMI_BCAST_VRING_CFG_CMDID = 0x822,
- WMI_VRING_BA_EN_CMDID = 0x823,
- WMI_VRING_BA_DIS_CMDID = 0x824,
- WMI_RCP_ADDBA_RESP_CMDID = 0x825,
- WMI_RCP_DELBA_CMDID = 0x826,
- WMI_SET_SSID_CMDID = 0x827,
- WMI_GET_SSID_CMDID = 0x828,
- WMI_SET_PCP_CHANNEL_CMDID = 0x829,
- WMI_GET_PCP_CHANNEL_CMDID = 0x82A,
- WMI_SW_TX_REQ_CMDID = 0x82B,
- WMI_READ_MAC_RXQ_CMDID = 0x830,
- WMI_READ_MAC_TXQ_CMDID = 0x831,
- WMI_WRITE_MAC_RXQ_CMDID = 0x832,
- WMI_WRITE_MAC_TXQ_CMDID = 0x833,
- WMI_WRITE_MAC_XQ_FIELD_CMDID = 0x834,
- WMI_MLME_PUSH_CMDID = 0x835,
- WMI_BEAMFORMING_MGMT_CMDID = 0x836,
- WMI_BF_TXSS_MGMT_CMDID = 0x837,
- WMI_BF_SM_MGMT_CMDID = 0x838,
- WMI_BF_RXSS_MGMT_CMDID = 0x839,
- WMI_BF_TRIG_CMDID = 0x83A,
- WMI_LINK_MAINTAIN_CFG_WRITE_CMDID = 0x842,
- WMI_LINK_MAINTAIN_CFG_READ_CMDID = 0x843,
- WMI_SET_SECTORS_CMDID = 0x849,
- WMI_MAINTAIN_PAUSE_CMDID = 0x850,
- WMI_MAINTAIN_RESUME_CMDID = 0x851,
- WMI_RS_MGMT_CMDID = 0x852,
- WMI_RF_MGMT_CMDID = 0x853,
- WMI_THERMAL_THROTTLING_CTRL_CMDID = 0x854,
- WMI_THERMAL_THROTTLING_GET_STATUS_CMDID = 0x855,
- WMI_OTP_READ_CMDID = 0x856,
- WMI_OTP_WRITE_CMDID = 0x857,
- WMI_LED_CFG_CMDID = 0x858,
+ WMI_CONNECT_CMDID = 0x01,
+ WMI_DISCONNECT_CMDID = 0x03,
+ WMI_DISCONNECT_STA_CMDID = 0x04,
+ WMI_START_SCAN_CMDID = 0x07,
+ WMI_SET_BSS_FILTER_CMDID = 0x09,
+ WMI_SET_PROBED_SSID_CMDID = 0x0A,
+ WMI_SET_LISTEN_INT_CMDID = 0x0B,
+ WMI_BCON_CTRL_CMDID = 0x0F,
+ WMI_ADD_CIPHER_KEY_CMDID = 0x16,
+ WMI_DELETE_CIPHER_KEY_CMDID = 0x17,
+ WMI_PCP_CONF_CMDID = 0x18,
+ WMI_SET_APPIE_CMDID = 0x3F,
+ WMI_SET_WSC_STATUS_CMDID = 0x41,
+ WMI_PXMT_RANGE_CFG_CMDID = 0x42,
+ WMI_PXMT_SNR2_RANGE_CFG_CMDID = 0x43,
+ WMI_MEM_READ_CMDID = 0x800,
+ WMI_MEM_WR_CMDID = 0x801,
+ WMI_ECHO_CMDID = 0x803,
+ WMI_DEEP_ECHO_CMDID = 0x804,
+ WMI_CONFIG_MAC_CMDID = 0x805,
+ WMI_CONFIG_PHY_DEBUG_CMDID = 0x806,
+ WMI_ADD_DEBUG_TX_PCKT_CMDID = 0x808,
+ WMI_PHY_GET_STATISTICS_CMDID = 0x809,
+ WMI_FS_TUNE_CMDID = 0x80A,
+ WMI_CORR_MEASURE_CMDID = 0x80B,
+ WMI_READ_RSSI_CMDID = 0x80C,
+ WMI_TEMP_SENSE_CMDID = 0x80E,
+ WMI_DC_CALIB_CMDID = 0x80F,
+ WMI_SEND_TONE_CMDID = 0x810,
+ WMI_IQ_TX_CALIB_CMDID = 0x811,
+ WMI_IQ_RX_CALIB_CMDID = 0x812,
+ WMI_SET_UCODE_IDLE_CMDID = 0x813,
+ WMI_SET_WORK_MODE_CMDID = 0x815,
+ WMI_LO_LEAKAGE_CALIB_CMDID = 0x816,
+ WMI_MARLON_R_READ_CMDID = 0x818,
+ WMI_MARLON_R_WRITE_CMDID = 0x819,
+ WMI_MARLON_R_TXRX_SEL_CMDID = 0x81A,
+ MAC_IO_STATIC_PARAMS_CMDID = 0x81B,
+ MAC_IO_DYNAMIC_PARAMS_CMDID = 0x81C,
+ WMI_SILENT_RSSI_CALIB_CMDID = 0x81D,
+ WMI_RF_RX_TEST_CMDID = 0x81E,
+ WMI_CFG_RX_CHAIN_CMDID = 0x820,
+ WMI_VRING_CFG_CMDID = 0x821,
+ WMI_BCAST_VRING_CFG_CMDID = 0x822,
+ WMI_VRING_BA_EN_CMDID = 0x823,
+ WMI_VRING_BA_DIS_CMDID = 0x824,
+ WMI_RCP_ADDBA_RESP_CMDID = 0x825,
+ WMI_RCP_DELBA_CMDID = 0x826,
+ WMI_SET_SSID_CMDID = 0x827,
+ WMI_GET_SSID_CMDID = 0x828,
+ WMI_SET_PCP_CHANNEL_CMDID = 0x829,
+ WMI_GET_PCP_CHANNEL_CMDID = 0x82A,
+ WMI_SW_TX_REQ_CMDID = 0x82B,
+ WMI_READ_MAC_RXQ_CMDID = 0x830,
+ WMI_READ_MAC_TXQ_CMDID = 0x831,
+ WMI_WRITE_MAC_RXQ_CMDID = 0x832,
+ WMI_WRITE_MAC_TXQ_CMDID = 0x833,
+ WMI_WRITE_MAC_XQ_FIELD_CMDID = 0x834,
+ WMI_MLME_PUSH_CMDID = 0x835,
+ WMI_BEAMFORMING_MGMT_CMDID = 0x836,
+ WMI_BF_TXSS_MGMT_CMDID = 0x837,
+ WMI_BF_SM_MGMT_CMDID = 0x838,
+ WMI_BF_RXSS_MGMT_CMDID = 0x839,
+ WMI_BF_TRIG_CMDID = 0x83A,
+ WMI_LINK_MAINTAIN_CFG_WRITE_CMDID = 0x842,
+ WMI_LINK_MAINTAIN_CFG_READ_CMDID = 0x843,
+ WMI_SET_SECTORS_CMDID = 0x849,
+ WMI_MAINTAIN_PAUSE_CMDID = 0x850,
+ WMI_MAINTAIN_RESUME_CMDID = 0x851,
+ WMI_RS_MGMT_CMDID = 0x852,
+ WMI_RF_MGMT_CMDID = 0x853,
+ WMI_THERMAL_THROTTLING_CTRL_CMDID = 0x854,
+ WMI_THERMAL_THROTTLING_GET_STATUS_CMDID = 0x855,
+ WMI_OTP_READ_CMDID = 0x856,
+ WMI_OTP_WRITE_CMDID = 0x857,
+ WMI_LED_CFG_CMDID = 0x858,
/* Performance monitoring commands */
- WMI_BF_CTRL_CMDID = 0x862,
- WMI_NOTIFY_REQ_CMDID = 0x863,
- WMI_GET_STATUS_CMDID = 0x864,
- WMI_GET_RF_STATUS_CMDID = 0x866,
- WMI_GET_BASEBAND_TYPE_CMDID = 0x867,
- WMI_UNIT_TEST_CMDID = 0x900,
- WMI_HICCUP_CMDID = 0x901,
- WMI_FLASH_READ_CMDID = 0x902,
- WMI_FLASH_WRITE_CMDID = 0x903,
+ WMI_BF_CTRL_CMDID = 0x862,
+ WMI_NOTIFY_REQ_CMDID = 0x863,
+ WMI_GET_STATUS_CMDID = 0x864,
+ WMI_GET_RF_STATUS_CMDID = 0x866,
+ WMI_GET_BASEBAND_TYPE_CMDID = 0x867,
+ WMI_UNIT_TEST_CMDID = 0x900,
+ WMI_HICCUP_CMDID = 0x901,
+ WMI_FLASH_READ_CMDID = 0x902,
+ WMI_FLASH_WRITE_CMDID = 0x903,
/* Power management */
- WMI_TRAFFIC_DEFERRAL_CMDID = 0x904,
- WMI_TRAFFIC_RESUME_CMDID = 0x905,
+ WMI_TRAFFIC_DEFERRAL_CMDID = 0x904,
+ WMI_TRAFFIC_RESUME_CMDID = 0x905,
/* P2P */
- WMI_P2P_CFG_CMDID = 0x910,
- WMI_PORT_ALLOCATE_CMDID = 0x911,
- WMI_PORT_DELETE_CMDID = 0x912,
- WMI_POWER_MGMT_CFG_CMDID = 0x913,
- WMI_START_LISTEN_CMDID = 0x914,
- WMI_START_SEARCH_CMDID = 0x915,
- WMI_DISCOVERY_START_CMDID = 0x916,
- WMI_DISCOVERY_STOP_CMDID = 0x917,
- WMI_PCP_START_CMDID = 0x918,
- WMI_PCP_STOP_CMDID = 0x919,
- WMI_GET_PCP_FACTOR_CMDID = 0x91B,
+ WMI_P2P_CFG_CMDID = 0x910,
+ WMI_PORT_ALLOCATE_CMDID = 0x911,
+ WMI_PORT_DELETE_CMDID = 0x912,
+ WMI_POWER_MGMT_CFG_CMDID = 0x913,
+ WMI_START_LISTEN_CMDID = 0x914,
+ WMI_START_SEARCH_CMDID = 0x915,
+ WMI_DISCOVERY_START_CMDID = 0x916,
+ WMI_DISCOVERY_STOP_CMDID = 0x917,
+ WMI_PCP_START_CMDID = 0x918,
+ WMI_PCP_STOP_CMDID = 0x919,
+ WMI_GET_PCP_FACTOR_CMDID = 0x91B,
/* Power Save Configuration Commands */
- WMI_PS_DEV_PROFILE_CFG_CMDID = 0x91C,
+ WMI_PS_DEV_PROFILE_CFG_CMDID = 0x91C,
/* Not supported yet */
- WMI_PS_DEV_CFG_CMDID = 0x91D,
+ WMI_PS_DEV_CFG_CMDID = 0x91D,
/* Not supported yet */
- WMI_PS_DEV_CFG_READ_CMDID = 0x91E,
+ WMI_PS_DEV_CFG_READ_CMDID = 0x91E,
/* Per MAC Power Save Configuration commands
* Not supported yet
*/
- WMI_PS_MID_CFG_CMDID = 0x91F,
+ WMI_PS_MID_CFG_CMDID = 0x91F,
/* Not supported yet */
- WMI_PS_MID_CFG_READ_CMDID = 0x920,
- WMI_RS_CFG_CMDID = 0x921,
- WMI_GET_DETAILED_RS_RES_CMDID = 0x922,
- WMI_AOA_MEAS_CMDID = 0x923,
- WMI_SET_MGMT_RETRY_LIMIT_CMDID = 0x930,
- WMI_GET_MGMT_RETRY_LIMIT_CMDID = 0x931,
- WMI_TOF_SESSION_START_CMDID = 0x991,
- WMI_TOF_GET_CAPABILITIES_CMDID = 0x992,
- WMI_TOF_SET_LCR_CMDID = 0x993,
- WMI_TOF_SET_LCI_CMDID = 0x994,
- WMI_TOF_CHANNEL_INFO_CMDID = 0x995,
- WMI_GET_RF_SECTOR_PARAMS_CMDID = 0x9A0,
- WMI_SET_RF_SECTOR_PARAMS_CMDID = 0x9A1,
- WMI_GET_SELECTED_RF_SECTOR_INDEX_CMDID = 0x9A2,
- WMI_SET_SELECTED_RF_SECTOR_INDEX_CMDID = 0x9A3,
- WMI_SET_RF_SECTOR_ON_CMDID = 0x9A4,
- WMI_SET_MAC_ADDRESS_CMDID = 0xF003,
- WMI_ABORT_SCAN_CMDID = 0xF007,
- WMI_SET_PROMISCUOUS_MODE_CMDID = 0xF041,
- WMI_GET_PMK_CMDID = 0xF048,
- WMI_SET_PASSPHRASE_CMDID = 0xF049,
- WMI_SEND_ASSOC_RES_CMDID = 0xF04A,
- WMI_SET_ASSOC_REQ_RELAY_CMDID = 0xF04B,
- WMI_MAC_ADDR_REQ_CMDID = 0xF04D,
- WMI_FW_VER_CMDID = 0xF04E,
- WMI_PMC_CMDID = 0xF04F,
+ WMI_PS_MID_CFG_READ_CMDID = 0x920,
+ WMI_RS_CFG_CMDID = 0x921,
+ WMI_GET_DETAILED_RS_RES_CMDID = 0x922,
+ WMI_AOA_MEAS_CMDID = 0x923,
+ WMI_SET_MGMT_RETRY_LIMIT_CMDID = 0x930,
+ WMI_GET_MGMT_RETRY_LIMIT_CMDID = 0x931,
+ WMI_TOF_SESSION_START_CMDID = 0x991,
+ WMI_TOF_GET_CAPABILITIES_CMDID = 0x992,
+ WMI_TOF_SET_LCR_CMDID = 0x993,
+ WMI_TOF_SET_LCI_CMDID = 0x994,
+ WMI_TOF_CHANNEL_INFO_CMDID = 0x995,
+ WMI_TOF_SET_TX_RX_OFFSET_CMDID = 0x997,
+ WMI_TOF_GET_TX_RX_OFFSET_CMDID = 0x998,
+ WMI_GET_RF_SECTOR_PARAMS_CMDID = 0x9A0,
+ WMI_SET_RF_SECTOR_PARAMS_CMDID = 0x9A1,
+ WMI_GET_SELECTED_RF_SECTOR_INDEX_CMDID = 0x9A2,
+ WMI_SET_SELECTED_RF_SECTOR_INDEX_CMDID = 0x9A3,
+ WMI_SET_RF_SECTOR_ON_CMDID = 0x9A4,
+ WMI_PRIO_TX_SECTORS_ORDER_CMDID = 0x9A5,
+ WMI_PRIO_TX_SECTORS_NUMBER_CMDID = 0x9A6,
+ WMI_PRIO_TX_SECTORS_SET_DEFAULT_CFG_CMDID = 0x9A7,
+ WMI_SET_MAC_ADDRESS_CMDID = 0xF003,
+ WMI_ABORT_SCAN_CMDID = 0xF007,
+ WMI_SET_PROMISCUOUS_MODE_CMDID = 0xF041,
+ WMI_GET_PMK_CMDID = 0xF048,
+ WMI_SET_PASSPHRASE_CMDID = 0xF049,
+ WMI_SEND_ASSOC_RES_CMDID = 0xF04A,
+ WMI_SET_ASSOC_REQ_RELAY_CMDID = 0xF04B,
+ WMI_MAC_ADDR_REQ_CMDID = 0xF04D,
+ WMI_FW_VER_CMDID = 0xF04E,
+ WMI_PMC_CMDID = 0xF04F,
};
/* WMI_CONNECT_CMDID */
@@ -959,6 +965,15 @@ struct wmi_tof_channel_info_cmd {
__le32 channel_info_report_request;
} __packed;
+/* WMI_TOF_SET_TX_RX_OFFSET_CMDID */
+struct wmi_tof_set_tx_rx_offset_cmd {
+ /* TX delay offset */
+ __le32 tx_offset;
+ /* RX delay offset */
+ __le32 rx_offset;
+ __le32 reserved[2];
+} __packed;
+
/* WMI Events
* List of Events (target to host)
*/
@@ -1060,11 +1075,16 @@ enum wmi_event_id {
WMI_TOF_SET_LCI_EVENTID = 0x1994,
WMI_TOF_FTM_PER_DEST_RES_EVENTID = 0x1995,
WMI_TOF_CHANNEL_INFO_EVENTID = 0x1996,
+ WMI_TOF_SET_TX_RX_OFFSET_EVENTID = 0x1997,
+ WMI_TOF_GET_TX_RX_OFFSET_EVENTID = 0x1998,
WMI_GET_RF_SECTOR_PARAMS_DONE_EVENTID = 0x19A0,
WMI_SET_RF_SECTOR_PARAMS_DONE_EVENTID = 0x19A1,
WMI_GET_SELECTED_RF_SECTOR_INDEX_DONE_EVENTID = 0x19A2,
WMI_SET_SELECTED_RF_SECTOR_INDEX_DONE_EVENTID = 0x19A3,
WMI_SET_RF_SECTOR_ON_DONE_EVENTID = 0x19A4,
+ WMI_PRIO_TX_SECTORS_ORDER_EVENTID = 0x19A5,
+ WMI_PRIO_TX_SECTORS_NUMBER_EVENTID = 0x19A6,
+ WMI_PRIO_TX_SECTORS_SET_DEFAULT_CFG_EVENTID = 0x19A7,
WMI_SET_CHANNEL_EVENTID = 0x9000,
WMI_ASSOC_REQ_EVENTID = 0x9001,
WMI_EAPOL_RX_EVENTID = 0x9002,
@@ -1190,6 +1210,7 @@ enum baseband_type {
BASEBAND_SPARROW_M_B0 = 0x05,
BASEBAND_SPARROW_M_C0 = 0x06,
BASEBAND_SPARROW_M_D0 = 0x07,
+ BASEBAND_TALYN_M_A0 = 0x08,
};
/* WMI_GET_BASEBAND_TYPE_EVENTID */
@@ -2224,6 +2245,25 @@ struct wmi_tof_channel_info_event {
u8 report[0];
} __packed;
+/* WMI_TOF_SET_TX_RX_OFFSET_EVENTID */
+struct wmi_tof_set_tx_rx_offset_event {
+ /* enum wmi_fw_status */
+ u8 status;
+ u8 reserved[3];
+} __packed;
+
+/* WMI_TOF_GET_TX_RX_OFFSET_EVENTID */
+struct wmi_tof_get_tx_rx_offset_event {
+ /* enum wmi_fw_status */
+ u8 status;
+ u8 reserved1[3];
+ /* TX delay offset */
+ __le32 tx_offset;
+ /* RX delay offset */
+ __le32 rx_offset;
+ __le32 reserved2[2];
+} __packed;
+
/* Result status codes for WMI commands */
enum wmi_rf_sector_status {
WMI_RF_SECTOR_STATUS_SUCCESS = 0x00,
@@ -2388,4 +2428,100 @@ struct wmi_set_rf_sector_on_done_event {
u8 reserved[3];
} __packed;
+enum wmi_sector_sweep_type {
+ WMI_SECTOR_SWEEP_TYPE_TXSS = 0x00,
+ WMI_SECTOR_SWEEP_TYPE_BCON = 0x01,
+ WMI_SECTOR_SWEEP_TYPE_TXSS_AND_BCON = 0x02,
+ WMI_SECTOR_SWEEP_TYPE_NUM = 0x03,
+};
+
+/* WMI_PRIO_TX_SECTORS_ORDER_CMDID
+ *
+ * Set the order of TX sectors in TXSS and/or Beacon(AP).
+ *
+ * Returned event:
+ * - WMI_PRIO_TX_SECTORS_ORDER_EVENTID
+ */
+struct wmi_prio_tx_sectors_order_cmd {
+ /* tx sectors order to be applied, 0xFF for end of array */
+ u8 tx_sectors_priority_array[MAX_NUM_OF_SECTORS];
+ /* enum wmi_sector_sweep_type, TXSS and/or Beacon */
+ u8 sector_sweep_type;
+ /* needed only for TXSS configuration */
+ u8 cid;
+ /* alignment to 32b */
+ u8 reserved[2];
+} __packed;
+
+/* completion status codes */
+enum wmi_prio_tx_sectors_cmd_status {
+ WMI_PRIO_TX_SECT_CMD_STATUS_SUCCESS = 0x00,
+ WMI_PRIO_TX_SECT_CMD_STATUS_BAD_PARAM = 0x01,
+ /* other error */
+ WMI_PRIO_TX_SECT_CMD_STATUS_ERROR = 0x02,
+};
+
+/* WMI_PRIO_TX_SECTORS_ORDER_EVENTID */
+struct wmi_prio_tx_sectors_order_event {
+ /* enum wmi_prio_tx_sectors_cmd_status */
+ u8 status;
+ /* alignment to 32b */
+ u8 reserved[3];
+} __packed;
+
+struct wmi_prio_tx_sectors_num_cmd {
+ /* [0-128], 0 = No changes */
+ u8 beacon_number_of_sectors;
+ /* [0-128], 0 = No changes */
+ u8 txss_number_of_sectors;
+ /* [0-8] needed only for TXSS configuration */
+ u8 cid;
+} __packed;
+
+/* WMI_PRIO_TX_SECTORS_NUMBER_CMDID
+ *
+ * Set the number of active sectors in TXSS and/or Beacon.
+ *
+ * Returned event:
+ * - WMI_PRIO_TX_SECTORS_NUMBER_EVENTID
+ */
+struct wmi_prio_tx_sectors_number_cmd {
+ struct wmi_prio_tx_sectors_num_cmd active_sectors_num;
+ /* alignment to 32b */
+ u8 reserved;
+} __packed;
+
+/* WMI_PRIO_TX_SECTORS_NUMBER_EVENTID */
+struct wmi_prio_tx_sectors_number_event {
+ /* enum wmi_prio_tx_sectors_cmd_status */
+ u8 status;
+ /* alignment to 32b */
+ u8 reserved[3];
+} __packed;
+
+/* WMI_PRIO_TX_SECTORS_SET_DEFAULT_CFG_CMDID
+ *
+ * Set default sectors order and number (hard coded in board file)
+ * in TXSS and/or Beacon.
+ *
+ * Returned event:
+ * - WMI_PRIO_TX_SECTORS_SET_DEFAULT_CFG_EVENTID
+ */
+struct wmi_prio_tx_sectors_set_default_cfg_cmd {
+ /* enum wmi_sector_sweep_type, TXSS and/or Beacon */
+ u8 sector_sweep_type;
+ /* needed only for TXSS configuration */
+ u8 cid;
+ /* alignment to 32b */
+ u8 reserved[2];
+} __packed;
+
+/* WMI_PRIO_TX_SECTORS_SET_DEFAULT_CFG_EVENTID */
+struct wmi_prio_tx_sectors_set_default_cfg_event {
+ /* enum wmi_prio_tx_sectors_cmd_status */
+ u8 status;
+ /* alignment to 32b */
+ u8 reserved[3];
+} __packed;
+
#endif /* __WILOCITY_WMI_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] wil6210: add debugfs blobs for UCODE code and data
From: Maya Erez @ 2016-11-28 11:49 UTC (permalink / raw)
To: Kalle Valo; +Cc: Lior David, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1480333743-7306-1-git-send-email-qca_merez@qca.qualcomm.com>
From: Lior David <qca_liord@qca.qualcomm.com>
Added new areas to fw_mappings area for UCODE code
and data areas.
The new areas are only exposed through debugfs blobs,
and mainly needed to access UCODE logs.
The change does not affect crash dumps because the
newly added areas overlap with the "upper" area which
is already dumped.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/wil6210.h | 3 +-
drivers/net/wireless/ath/wil6210/wil_crash_dump.c | 6 ++++
drivers/net/wireless/ath/wil6210/wmi.c | 39 +++++++++++++++--------
3 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index ef95db9..237e166 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -276,10 +276,11 @@ struct fw_map {
u32 to; /* linker address - to, exclusive */
u32 host; /* PCI/Host address - BAR0 + 0x880000 */
const char *name; /* for debugfs */
+ bool fw; /* true if FW mapping, false if UCODE mapping */
};
/* array size should be in sync with actual definition in the wmi.c */
-extern const struct fw_map fw_mapping[8];
+extern const struct fw_map fw_mapping[10];
/**
* mk_cidxtid - construct @cidxtid field
diff --git a/drivers/net/wireless/ath/wil6210/wil_crash_dump.c b/drivers/net/wireless/ath/wil6210/wil_crash_dump.c
index b57d280..d051eea 100644
--- a/drivers/net/wireless/ath/wil6210/wil_crash_dump.c
+++ b/drivers/net/wireless/ath/wil6210/wil_crash_dump.c
@@ -36,6 +36,9 @@ static int wil_fw_get_crash_dump_bounds(struct wil6210_priv *wil,
for (i = 1; i < ARRAY_SIZE(fw_mapping); i++) {
map = &fw_mapping[i];
+ if (!map->fw)
+ continue;
+
if (map->host < host_min)
host_min = map->host;
@@ -73,6 +76,9 @@ int wil_fw_copy_crash_dump(struct wil6210_priv *wil, void *dest, u32 size)
for (i = 0; i < ARRAY_SIZE(fw_mapping); i++) {
map = &fw_mapping[i];
+ if (!map->fw)
+ continue;
+
data = (void * __force)wil->csr + HOSTADDR(map->host);
len = map->to - map->from;
offset = map->host - host_min;
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index d289a4d..7585003 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -84,19 +84,29 @@
* array size should be in sync with the declaration in the wil6210.h
*/
const struct fw_map fw_mapping[] = {
- {0x000000, 0x040000, 0x8c0000, "fw_code"}, /* FW code RAM 256k */
- {0x800000, 0x808000, 0x900000, "fw_data"}, /* FW data RAM 32k */
- {0x840000, 0x860000, 0x908000, "fw_peri"}, /* periph. data RAM 128k */
- {0x880000, 0x88a000, 0x880000, "rgf"}, /* various RGF 40k */
- {0x88a000, 0x88b000, 0x88a000, "AGC_tbl"}, /* AGC table 4k */
- {0x88b000, 0x88c000, 0x88b000, "rgf_ext"}, /* Pcie_ext_rgf 4k */
- {0x88c000, 0x88c200, 0x88c000, "mac_rgf_ext"}, /* mac_ext_rgf 512b */
- {0x8c0000, 0x949000, 0x8c0000, "upper"}, /* upper area 548k */
- /*
- * 920000..930000 ucode code RAM
- * 930000..932000 ucode data RAM
- * 932000..949000 back-door debug data
+ /* FW code RAM 256k */
+ {0x000000, 0x040000, 0x8c0000, "fw_code", true},
+ /* FW data RAM 32k */
+ {0x800000, 0x808000, 0x900000, "fw_data", true},
+ /* periph data 128k */
+ {0x840000, 0x860000, 0x908000, "fw_peri", true},
+ /* various RGF 40k */
+ {0x880000, 0x88a000, 0x880000, "rgf", true},
+ /* AGC table 4k */
+ {0x88a000, 0x88b000, 0x88a000, "AGC_tbl", true},
+ /* Pcie_ext_rgf 4k */
+ {0x88b000, 0x88c000, 0x88b000, "rgf_ext", true},
+ /* mac_ext_rgf 512b */
+ {0x88c000, 0x88c200, 0x88c000, "mac_rgf_ext", true},
+ /* upper area 548k */
+ {0x8c0000, 0x949000, 0x8c0000, "upper", true},
+ /* UCODE areas - accessible by debugfs blobs but not by
+ * wmi_addr_remap. UCODE areas MUST be added AFTER FW areas!
*/
+ /* ucode code RAM 128k */
+ {0x000000, 0x020000, 0x920000, "uc_code", false},
+ /* ucode data RAM 16k */
+ {0x800000, 0x804000, 0x940000, "uc_data", false},
};
struct blink_on_off_time led_blink_time[] = {
@@ -108,7 +118,7 @@ struct blink_on_off_time led_blink_time[] = {
u8 led_polarity = LED_POLARITY_LOW_ACTIVE;
/**
- * return AHB address for given firmware/ucode internal (linker) address
+ * return AHB address for given firmware internal (linker) address
* @x - internal address
* If address have no valid AHB mapping, return 0
*/
@@ -117,7 +127,8 @@ static u32 wmi_addr_remap(u32 x)
uint i;
for (i = 0; i < ARRAY_SIZE(fw_mapping); i++) {
- if ((x >= fw_mapping[i].from) && (x < fw_mapping[i].to))
+ if (fw_mapping[i].fw &&
+ ((x >= fw_mapping[i].from) && (x < fw_mapping[i].to)))
return x + fw_mapping[i].host - fw_mapping[i].from;
}
--
1.9.1
^ 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