* [PATCH] wireless-regdb: Extend 5470-5725 MHz range to 5730 MHz for Taiwan (TW)
From: Chen-Yu Tsai @ 2019-07-26 3:05 UTC (permalink / raw)
To: seth.forshee; +Cc: Chen-Yu Tsai, wireless-regdb, linux-wireless
From: Chen-Yu Tsai <wens@csie.org>
This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
The Linux kernel however does not seem capable of considering them
most restrictive subset of multiple rules.
Since 5725 ~ 5730 MHz belongs to the next range which has looser
requirements, we can do this manually and extend the range by 5 MHz
to make the kernel happy and be able to use channel 144.
Also, looking at the US regulations, which the TW ones are based on,
The DFS range ends at 5730 MHz, while the next range starts at 5735
MHz. This doesn't match the actual regulations, but is skewed to meet
wireless channel boundaries. I prefer the database match the law,
and be adjuested only if necessary.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
I have a vague impression that you asked about the range boundaries
when I first updated the rules for Taiwan. And here we are again.
---
db.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 37393e6..2e149b6 100644
--- a/db.txt
+++ b/db.txt
@@ -1249,7 +1249,11 @@ country TW: DFS-FCC
# 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (23), DFS, AUTO-BW
- (5470 - 5725 @ 160), (23), DFS
+ # This range ends at 5725 MHz, but channel 144 extends to 5730 MHz.
+ # Since 5725 ~ 5730 MHz belongs to the next range which has looser
+ # requirements, we can extend the range by 5 MHz to make the kernel
+ # happy and be able to use channel 144.
+ (5470 - 5730 @ 160), (23), DFS
(5725 - 5850 @ 80), (30)
# 60g band, LP0002 section 3.13.1.1 (3)(C), EIRP=40dBm(43dBm peak)
(57000 - 66000 @ 2160), (40)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Jian-Hong Pan @ 2019-07-26 6:18 UTC (permalink / raw)
To: David Laight
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <06d713fff7434dfb9ccab32c2e2112e2@AcuMS.aculab.com>
David Laight <David.Laight@aculab.com> 於 2019年7月25日 週四 下午5:21寫道：
>
> From: Jian-Hong Pan
> > Sent: 25 July 2019 09:09
> > Each skb as the element in RX ring was expected with sized buffer 8216
> > (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is
> > 16640 bytes for alignment after allocated, x86_64 for example. And, the
> > difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM).
> > To prevent that much wasted memory, this patch follows David's
> > suggestion [1] and uses general buffer arrays, instead of skbs as the
> > elements in RX ring.
> ...
> > for (i = 0; i < len; i++) {
> > - skb = dev_alloc_skb(buf_sz);
> > - if (!skb) {
> > + buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC);
>
> You should do this allocation somewhere than can sleep.
> So you don't need GFP_ATOMIC, making the allocate (and dma map)
> much less likely to fail.
> If they do fail using a smaller ring might be better than failing
> completely.
Ok, I can tweak and try it.
> I suspect that buf_sz gets rounded up somewhat.
> Also you almost certainly want 'buf' to be cache-line aligned.
> I don't think devm_kzalloc() guarantees that at all.
Sure
> While allocating all 512 buffers in one block (just over 4MB)
> is probably not a good idea, you may need to allocated (and dma map)
> then in groups.
Thanks for reviewing. But got questions here to double confirm the idea.
According to original code, it allocates 512 skbs for RX ring and dma
mapping one by one. So, the new code allocates memory buffer 512
times to get 512 buffer arrays. Will the 512 buffers arrays be in one
block? Do you mean aggregate the buffers as a scatterlist and use
dma_map_sg?
Thank you,
Jain-Hong Pan
^ permalink raw reply
* Re: [PATCH 0/3] ath10k: Clean up regulator and clock handling
From: Govind Singh @ 2019-07-26 6:52 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Kalle Valo, David S. Miller, ath10k, linux-wireless, netdev,
linux-kernel, linux-arm-msm
In-Reply-To: <20190725174755.23432-1-bjorn.andersson@linaro.org>
On 2019-07-25 23:17, Bjorn Andersson wrote:
> The first patch in this series removes the regulator_set_voltage() of a
> fixed
> voltate, as fixed regulator constraints should be specified on a board
> level
> and on certain boards - such as the Lenovo Yoga C630 - the voltage
> specified
> for the 3.3V regulator is outside the given range.
>
> The following two patches cleans up regulator and clock usage by using
> the bulk
> API provided by the two frameworks.
>
> Bjorn Andersson (3):
> ath10k: snoc: skip regulator operations
> ath10k: Use standard regulator bulk API in snoc
> ath10k: Use standard bulk clock API in snoc
>
> drivers/net/wireless/ath/ath10k/snoc.c | 324 ++++---------------------
> drivers/net/wireless/ath/ath10k/snoc.h | 26 +-
> 2 files changed, 48 insertions(+), 302 deletions(-)
Tested on 845 MTP and QCS404 platform with normal sanity and driver
recover cases for proxy votes.
Tested-by: Govind Singh <govinds@codeaurora.org>
Reviewed-by: Govind Singh <govinds@codeaurora.org>
BR,
Govind
^ permalink raw reply
* Re: mt76x0u blocks resume from suspend
From: Johannes Stezenbach @ 2019-07-26 6:52 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Lorenzo Bianconi, Felix Fietkau, linux-wireless
In-Reply-To: <20190723071806.GA2892@redhat.com>
Hi Stanislaw,
On Tue, Jul 23, 2019 at 09:18:07AM +0200, Stanislaw Gruszka wrote:
> On Mon, Jul 22, 2019 at 06:40:20PM +0200, Johannes Stezenbach wrote:
> > I met failure to resume from suspend to RAM with v5.1.19
> > and TP-Link Archer T2UH connected to my PC (Asus P8H77-V).
> > I tried about a dozen times while trying to figure out the reason,
> > the issue happened every time.
> > Eventually I connected a serial console and captured this:
> >
> > [ 87.803576][ T4640] mt76x0u 2-1.6:1.0: vendor request req:06 off:ac80 failed:-110
> > [ 91.030328][ T4640] mt76x0u 2-1.6:1.0: vendor request req:07 off:b000 failed:-110
> > [ 94.256950][ T4640] mt76x0u 2-1.6:1.0: vendor request req:06 off:b000 failed:-110
> > [ 97.483579][ T4640] mt76x0u 2-1.6:1.0: vendor request req:06 off:aca0 failed:-110
> > (repeats)
> > [ 107.492106][ C0] Call Trace:
> > [ 107.495293][ C0] ? __schedule+0x381/0xa30
> > [ 107.499706][ C0] schedule+0x36/0x90
> > [ 107.503575][ C0] schedule_timeout+0x1e8/0x4c0
> > [ 107.508310][ C0] ? collect_expired_timers+0xb0/0xb0
> > [ 107.513593][ C0] wait_for_common+0x15f/0x190
> > [ 107.518249][ C0] ? wake_up_q+0x80/0x80
> > [ 107.522412][ C0] usb_start_wait_urb+0x82/0x160
> > [ 107.527222][ C0] ? wait_for_common+0x38/0x190
> > [ 107.531961][ C0] usb_control_msg+0xdc/0x140
> > [ 107.536542][ C0] __mt76u_vendor_request+0xc4/0x100 [mt76_usb]
> > [ 107.542687][ C0] mt76u_copy+0x8b/0xb0 [mt76_usb]
> > [ 107.547721][ C0] mt76x02_mac_shared_key_setup+0xdf/0x130 [mt76x02_lib]
> <snip>
> > The whole machine is hanging at this point. without serial console
> > my only choice was to press the reset button. At least mt76x0u should
> > bail out with an error and not block the resume completely.
> > Unplugging the hardware also didn't cause it to bail.
>
> I recently sent fix for that
> https://lore.kernel.org/linux-wireless/1563446290-2813-1-git-send-email-sgruszka@redhat.com/raw
Although the error message you quote in your patch is
different than what I got, your patch works for me, too.
Thanks,
Johannes
^ permalink raw reply
* Re: [PATCH v2 1/3] Bluetooth: btintel: Add firmware lock function
From: Johannes Berg @ 2019-07-26 7:01 UTC (permalink / raw)
To: Kai-Heng Feng, Marcel Holtmann
Cc: Luciano Coelho, Johan Hedberg, linuxwifi, linux-wireless,
linux-bluetooth
In-Reply-To: <B50A91CA-7379-42F9-8335-8FE4A51BE66F@canonical.com>
[trimming CCs a bit]
> > so I am not in favor of this solution. The hardware guys should start
> > looking into fixing the firmware loading and provide proper firmware that
> > can be loaded at the same time.
>
> Of course it’s much better to fix from hardware side.
I tried to ask around a bit, and am told that a firmware fix (to just
retry the relevant hardware block access) was made. I'll try to figure
out where/how it was (or wasn't?) released.
johannes
^ permalink raw reply
* Re: Bug in iw ... scan output for Ad-Hoc (IBSS) output
From: Johannes Berg @ 2019-07-26 7:18 UTC (permalink / raw)
To: Bill Unruh, linux-wireless
In-Reply-To: <alpine.LMD.2.03.1907251251170.5032@physics.ubc.ca>
On Thu, 2019-07-25 at 13:04 -0700, Bill Unruh wrote:
> The output of iw .. scan output for Ad-Hoc (IBSS) does not have a carriage
> return running it into the next access point output
>
>
> BSS f6:63:9f:d1:f9:17(on wlp58s0)
> TSF: 0 usec (0d, 00:00:00)
> freq: 2437
> beacon interval: 100 TUs
> capability: IBSS ShortPreamble (0x0022)
> signal: -69.00 dBm
> last seen: 6040 ms ago
> Information elements from Probe Response frame:
> SSID: hpsetup
> Supported rates: 1.0* 2.0* 5.5* 11.0*
> DS Parameter set: channel 6
> IBSS ATIM window: 0 TUsBSS 34:31:c4:39:63:ef(on wlp58s0)
>
> Note the last line-- that is the BSS of the next access point output of iw
Thanks for the report, pushed a fix.
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-26 7:36 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190712105212.clf77zne6i4gh5ti@bars>
Hi Sergey,
Sorry for dropping the ball on this thread.
> > Right, it will be updated on RX. But then if we chanswitch, we would
> > probably (mac80211 using a pointer to the non-transmitting BSS) update
> > only one of the nontransmitting BSSes?
> >
> > Just saying that maybe we need to be careful there - or your wording
> > might be incorrect. We might end up updating a *nontransmitting* BSS,
> > and then its transmitting/other non-tx ones only later?
>
> Hmmm... I am not sure we are on the same page here. Could you please
> clarify your concerns here ?
I'm trying to say we might have this:
cfg80211
* transmitting BSS 0
- nontx BSS 1
- nontx BSS 2
- nontx BSS 3
mac80211
* ifmgd->associated (and cfg80211's wdev->current_bss?) = nontx BSS 2
Now, things like the channel information etc. will always be identical
between the 4 BSSes, by definition.
However, if you chanswitch and mac80211 just lets cfg80211 know about
the current_bss, then you may end up in a situation where the channel
information is no longer the same, which is very surprising.
> The normal (non multi-BSSID) BSS usecase seem to be clear: keep old and
> remove new (if any), since it is not easy to update ifmgd->associated.
Right.
> Now let me take another look at the usecase when STA is connected to
> a transmitting or non-transmitting BSS of a multi-BSS AP. At the moment
> suggested code does the following. If STA is connected to the non-transmitting
> BSS, then we switch to its transmitting BSS, instead of working with
> current_bss directly.
We switch? Where? Maybe I missed that.
> So we look for the new entry (with new channel) of the transmitting BSS.
> If it exists, then we remove it and _all_ of its non-transmitting BSSs.
> Finally, we update channel and location in rb-tree of the existing (old)
> transmitting BSS as well as _all_ of its non-transmitting entries.
That would indeed address the scenario I was thinking of ...
johannes
^ permalink raw reply
* RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: David Laight @ 2019-07-26 9:23 UTC (permalink / raw)
To: 'Jian-Hong Pan'
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <CAPpJ_ecAAw=1X=7+MOw-VVH0ZKBr6rcRub6JnEqgNbZ6Hxt=ag@mail.gmail.com>
From: Jian-Hong Pan
> Sent: 26 July 2019 07:18
...
> > While allocating all 512 buffers in one block (just over 4MB)
> > is probably not a good idea, you may need to allocated (and dma map)
> > then in groups.
>
> Thanks for reviewing. But got questions here to double confirm the idea.
> According to original code, it allocates 512 skbs for RX ring and dma
> mapping one by one. So, the new code allocates memory buffer 512
> times to get 512 buffer arrays. Will the 512 buffers arrays be in one
> block? Do you mean aggregate the buffers as a scatterlist and use
> dma_map_sg?
If you malloc a buffer of size (8192+32) the allocator will either
round it up to a whole number of (often 4k) pages or to a power of
2 of pages - so either 12k of 16k.
I think the Linux allocator does the latter.
Some of the allocators also 'steal' a bit from the front of the buffer
for 'red tape'.
OTOH malloc the space 15 buffers and the allocator will round the
15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
buffers.
You then dma_map the large buffer and split into the actual rx buffers.
Repeat until you've filled the entire ring.
The only complication is remembering the base address (and size) for
the dma_unmap and free.
Although there is plenty of padding to extend the buffer structure
significantly without using more memory.
Allocate in 15's and you (probably) have 512 bytes per buffer.
Allocate in 31's and you have 256 bytes.
The problem is that larger allocates are more likely to fail
(especially if the system has been running for some time).
So you almost certainly want to be able to fall back to smaller
allocates even though they use more memory.
I also wonder if you actually need 512 8k rx buffers to cover
interrupt latency?
I've not done any measurements for 20 years!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Jian-Hong Pan @ 2019-07-26 9:40 UTC (permalink / raw)
To: David Laight
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <c2cdffd30923459e8773379fc2927e1d@AcuMS.aculab.com>
David Laight <David.Laight@aculab.com> 於 2019年7月26日 週五 下午5:23寫道：
>
> From: Jian-Hong Pan
> > Sent: 26 July 2019 07:18
> ...
> > > While allocating all 512 buffers in one block (just over 4MB)
> > > is probably not a good idea, you may need to allocated (and dma map)
> > > then in groups.
> >
> > Thanks for reviewing. But got questions here to double confirm the idea.
> > According to original code, it allocates 512 skbs for RX ring and dma
> > mapping one by one. So, the new code allocates memory buffer 512
> > times to get 512 buffer arrays. Will the 512 buffers arrays be in one
> > block? Do you mean aggregate the buffers as a scatterlist and use
> > dma_map_sg?
>
> If you malloc a buffer of size (8192+32) the allocator will either
> round it up to a whole number of (often 4k) pages or to a power of
> 2 of pages - so either 12k of 16k.
> I think the Linux allocator does the latter.
> Some of the allocators also 'steal' a bit from the front of the buffer
> for 'red tape'.
>
> OTOH malloc the space 15 buffers and the allocator will round the
> 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
> buffers.
>
> You then dma_map the large buffer and split into the actual rx buffers.
> Repeat until you've filled the entire ring.
> The only complication is remembering the base address (and size) for
> the dma_unmap and free.
> Although there is plenty of padding to extend the buffer structure
> significantly without using more memory.
> Allocate in 15's and you (probably) have 512 bytes per buffer.
> Allocate in 31's and you have 256 bytes.
>
> The problem is that larger allocates are more likely to fail
> (especially if the system has been running for some time).
> So you almost certainly want to be able to fall back to smaller
> allocates even though they use more memory.
>
> I also wonder if you actually need 512 8k rx buffers to cover
> interrupt latency?
> I've not done any measurements for 20 years!
Thanks for the explanation.
I am not sure the combination of 512 8k RX buffers. Maybe Realtek
folks can give us some idea.
Tony Chuang any comment?
Jian-Hong Pan
^ permalink raw reply
* [PATCH] ipw2x00: remove redundant assignment to err
From: Colin King @ 2019-07-26 10:06 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable err is initialized to a value that is never read and it
is re-assigned later. The initialization is redundant and can
be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 75c0c29d81f0..8dfbaff2d1fe 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4413,7 +4413,7 @@ static void ipw2100_kill_works(struct ipw2100_priv *priv)
static int ipw2100_tx_allocate(struct ipw2100_priv *priv)
{
- int i, j, err = -EINVAL;
+ int i, j, err;
void *v;
dma_addr_t p;
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch
From: Sergey Matyukevich @ 2019-07-26 10:11 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <2efa83ab8120e29d1eb1be8295d59568b4eacc9a.camel@sipsolutions.net>
Hello Johannes,
> > > Right, it will be updated on RX. But then if we chanswitch, we would
> > > probably (mac80211 using a pointer to the non-transmitting BSS) update
> > > only one of the nontransmitting BSSes?
> > >
> > > Just saying that maybe we need to be careful there - or your wording
> > > might be incorrect. We might end up updating a *nontransmitting* BSS,
> > > and then its transmitting/other non-tx ones only later?
> >
> > Hmmm... I am not sure we are on the same page here. Could you please
> > clarify your concerns here ?
>
> I'm trying to say we might have this:
>
> cfg80211
> * transmitting BSS 0
> - nontx BSS 1
> - nontx BSS 2
> - nontx BSS 3
> mac80211
> * ifmgd->associated (and cfg80211's wdev->current_bss?) = nontx BSS 2
Yes, this is the use-case that I tried to address in the last revision
of the patch. Suggested approach is similar to what is done for normal
case:
- to keep this hierarchy updating channels and location in rb-tree
- remove newly added hierarchy of the same transmitting BSS on the new
channel
Note that here we update/remove not only transmitting BSSs, but their
nontx BSS hierarchies as well.
>
>
> Now, things like the channel information etc. will always be identical
> between the 4 BSSes, by definition.
>
> However, if you chanswitch and mac80211 just lets cfg80211 know about
> the current_bss, then you may end up in a situation where the channel
> information is no longer the same, which is very surprising.
>
>
> > The normal (non multi-BSSID) BSS usecase seem to be clear: keep old and
> > remove new (if any), since it is not easy to update ifmgd->associated.
>
> Right.
>
> > Now let me take another look at the usecase when STA is connected to
> > a transmitting or non-transmitting BSS of a multi-BSS AP. At the moment
> > suggested code does the following. If STA is connected to the non-transmitting
> > BSS, then we switch to its transmitting BSS, instead of working with
> > current_bss directly.
>
> We switch? Where? Maybe I missed that.
If you take a look at the top of new cfg80211_update_assoc_bss_entry
function:
+ /* use transmitting bss */
+ if (cbss->pub.transmitted_bss)
+ cbss = container_of(cbss->pub.transmitted_bss,
+ struct cfg80211_internal_bss,
+ pub);
> > So we look for the new entry (with new channel) of the transmitting BSS.
> > If it exists, then we remove it and _all_ of its non-transmitting BSSs.
> > Finally, we update channel and location in rb-tree of the existing (old)
> > transmitting BSS as well as _all_ of its non-transmitting entries.
>
> That would indeed address the scenario I was thinking of ...
Ok! Let me know if you have any other concerns or questions.
Actually one of the major concerns is the lack of testing for the 'multi-BSSID'
scenario. I verified the 'normal' scenario using both mac80211 (iwlwifi) and
FullMAC (qtnfmac) cards. But at the moment I don't have any mac80211 card
supporting multi-BSSID.
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH] mac80211: reject zero MAC address in add station
From: Johannes Berg @ 2019-07-26 11:06 UTC (permalink / raw)
To: Karthikeyan Periyasamy; +Cc: linux-wireless
In-Reply-To: <1563959770-21570-1-git-send-email-periyasa@codeaurora.org>
On Wed, 2019-07-24 at 14:46 +0530, Karthikeyan Periyasamy wrote:
> Don't allow using a zero MAC address as the station
> MAC address. so validated the MAC address using
> is_valid_ether_addr.
Theoretically, all zeroes might have been a valid address at some point.
I see no reason not to reject it, but I'd like to know why you ended up
with this now??
johannes
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-07-20
From: Josh Boyer @ 2019-07-26 11:29 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk, dor.shaish
In-Reply-To: <b8246cb77dfc2d1344cd194682001a11a01dbf3a.camel@coelho.fi>
On Sat, Jul 20, 2019 at 4:03 AM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some updated firmwares for all our currently maintained
> FW binaries.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit bf13a71b18af229b4c900b321ef1f8443028ded8:
>
> Merge branch 'guc_v33' of git://anongit.freedesktop.org/drm/drm-firmware (2019-07-17 09:05:52 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-07-20
>
> for you to fetch changes up to cd6cb7bc50aa77d531c4417ffe1237510b71c73e:
>
> iwlwifi: update -48 FWs for Qu and cc (2019-07-20 10:58:24 +0300)
>
> ----------------------------------------------------------------
> iwlwifi: update a bunch of FW binaries
>
> ----------------------------------------------------------------
> Luca Coelho (2):
> iwlwifi: update FWs for 3168, 7265D, 9000, 9260, 8000, 8265 and cc
> iwlwifi: update -48 FWs for Qu and cc
>
> iwlwifi-3168-29.ucode | Bin 1036276 -> 1036300 bytes
> iwlwifi-7265D-29.ucode | Bin 1036432 -> 1036668 bytes
> iwlwifi-8000C-36.ucode | Bin 2400700 -> 2401356 bytes
> iwlwifi-8265-36.ucode | Bin 2414296 -> 2414592 bytes
> iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 1460788 -> 1467952 bytes
> iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 1462324 -> 1469012 bytes
> iwlwifi-Qu-b0-hr-b0-48.ucode | Bin 1106208 -> 1106204 bytes
> iwlwifi-Qu-b0-jf-b0-48.ucode | Bin 1053156 -> 1052772 bytes
> iwlwifi-Qu-c0-hr-b0-48.ucode | Bin 1106228 -> 1106224 bytes
> iwlwifi-Qu-c0-jf-b0-48.ucode | Bin 1053176 -> 1052792 bytes
> iwlwifi-QuZ-a0-hr-b0-48.ucode | Bin 1105648 -> 1105644 bytes
> iwlwifi-QuZ-a0-jf-b0-48.ucode | Bin 1052968 -> 1052584 bytes
> iwlwifi-cc-a0-46.ucode | Bin 1044072 -> 1044452 bytes
> iwlwifi-cc-a0-48.ucode | Bin 1096684 -> 1096680 bytes
> 14 files changed, 0 insertions(+), 0 deletions(-)
Pulled and pushed out.
josh
^ permalink raw reply
* Re: [PATCH V3 2/2] mac80211: add support for the ADDBA extension element
From: Johannes Berg @ 2019-07-26 11:36 UTC (permalink / raw)
To: John Crispin; +Cc: linux-wireless, Shashidhar Lakkavalli
In-Reply-To: <20190713163642.18491-3-john@phrozen.org>
Hi,
Apologies for the late review.
I've applied patch 1, but not this one yet:
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_2 0x10
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_3 0x18
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK 0x18
> +#define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_SHIFT 3
this will not be needed,
> -static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *da, u16 tid,
> +static void ieee80211_add_addbaext(struct ieee80211_sub_if_data *sdata,
> + struct sk_buff *skb,
> + const struct ieee80211_addba_ext_ie *req)
> +{
> + struct ieee80211_supported_band *sband;
> + struct ieee80211_addba_ext_ie *resp;
> + const struct ieee80211_sta_he_cap *he_cap;
> + u8 frag_level, cap_frag_level;
> + u8 *pos;
> +
> + sband = ieee80211_get_sband(sdata);
> + he_cap = ieee80211_get_he_iftype_cap(sband, sdata->vif.type);
> + if (!he_cap)
> + return;
> +
> + pos = skb_put_zero(skb, 2 + sizeof(struct ieee80211_addba_ext_ie));
> + *pos++ = WLAN_EID_ADDBA_EXT;
> + *pos++ = sizeof(struct ieee80211_addba_ext_ie);
> + resp = (struct ieee80211_addba_ext_ie *)pos;
> + resp->data = req->data & IEEE80211_ADDBA_EXT_NO_FRAG;
> +
> + frag_level = (req->data & IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK) >>
> + IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT;
> + cap_frag_level = (he_cap->he_cap_elem.mac_cap_info[0] &
> + IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK) >>
> + IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_SHIFT;
if you use u32_get_bits() from bitfield.h here for these two
assignments, which is nicer anyway.
> + if (frag_level > cap_frag_level)
> + frag_level = cap_frag_level;
> + resp->data |= (frag_level << IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT) &
> + IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK;
and probably that could also be u8_encode_bits()?
> - skb = dev_alloc_skb(sizeof(*mgmt) + local->hw.extra_tx_headroom);
> + skb = dev_alloc_skb(sizeof(*mgmt) +
> + (addbaext ? 2 + sizeof(struct ieee80211_addba_ext_ie) : 0) +
> + local->hw.extra_tx_headroom);
not much point in the if (ternary operator) for ... 3 bytes? :-)
johannes
^ permalink raw reply
* Re: [PATCH V3 2/2] mac80211: allow setting spatial reuse parameters from bss_conf
From: Johannes Berg @ 2019-07-26 11:48 UTC (permalink / raw)
To: John Crispin; +Cc: linux-wireless, Shashidhar Lakkavalli
In-Reply-To: <20190618061915.7102-3-john@phrozen.org>
On Tue, 2019-06-18 at 08:19 +0200, John Crispin wrote:
> Store the OBSS PD parameters inside bss_conf when bringing up an AP and/or
> when a station connects to an AP. This allows the driver to configure the
> HW accordingly.
>
> Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
> Signed-off-by: John Crispin <john@phrozen.org>
> ---
> include/net/cfg80211.h | 15 +++++++++++++
> include/net/mac80211.h | 4 ++++
> include/uapi/linux/nl80211.h | 27 ++++++++++++++++++++++
> net/mac80211/cfg.c | 5 ++++-
> net/mac80211/he.c | 24 ++++++++++++++++++++
> net/mac80211/ieee80211_i.h | 3 +++
> net/mac80211/mlme.c | 1 +
> net/wireless/nl80211.c | 43 ++++++++++++++++++++++++++++++++++++
> 8 files changed, 121 insertions(+), 1 deletion(-)
Not sure if I missed this before, but in any case please split between
cfg80211 and mac80211 for all but the most trivial patches.
> +/**
> + * enum nl80211_he_spr - spatial reuse attributes
bad copy/paste? :)
> + * @__NL80211_HE_OBSS_PD_ATTR_INVALID: Invalid
> + *
> + * @NL80211_ATTR_HE_OBSS_PD_MIN_OFFSET: the OBSS PD minimum tx power offset.
> + * @NL80211_ATTR_HE_OBSS_PD_MAX_OFFSET: the OBSS PD maximum tx power offset.
> + *
> + * @__NL80211_HE_OBSS_PD_ATTR_LAST: Internal
> + * @NL80211_HE_OBSS_PD_ATTR_MAX: highest spiatl reuse attribute.
typo & wrong anyway, OBSS PD not SPR
> + */
Those prefixes are a bit confusing - IMHO they should all be
NL80211_HE_OBSS_PD_ATTR_*, NL80211_ATTR_* is mostly (except for a few
historical bugs) the top-level attributes.
> +enum nl80211_he_spr_attributes {
here also
> + memcpy(&sdata->vif.bss_conf.he_obss_pd, ¶ms->he_obss_pd,
> + sizeof(struct ieee80211_he_obss_pd));
just use struct assignment
blabla.he_obss_pd = params->he_obss_pd;
> + [NL80211_ATTR_HE_OBSS_PD] = { .type = NLA_NESTED },
please use NLA_POLICY_NESTED() (requires putting the below policy above
this point)
> +static const struct nla_policy
> + he_spr_policy[NL80211_HE_OBSS_PD_ATTR_MAX + 1] = {
I guess I'd lose all the tabs here but don't really care that much.
> + [NL80211_ATTR_HE_OBSS_PD_MIN_OFFSET] = { .type = NLA_U32 },
> + [NL80211_ATTR_HE_OBSS_PD_MAX_OFFSET] = { .type = NLA_U32 },
That can't be right, they go into u8 eventually, no? Use NLA_U8 or maybe
even NLA_POLICY_RANGE().
Also in the struct ieee80211_he_obss_pd you have u32 for no real reason?
In the element in the frame you only used a single u8.
> + if (!tb[NL80211_ATTR_HE_OBSS_PD_MIN_OFFSET] ||
> + !tb[NL80211_ATTR_HE_OBSS_PD_MAX_OFFSET])
> + return -EINVAL;
> + if (he_obss_pd->min_offset >= he_obss_pd->max_offset)
> + return -EINVAL;
Maybe add some extack error messages for this.
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-26 12:02 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190726101150.lykay6apgzvsb4ov@bars>
Hi Sergey,
> Yes, this is the use-case that I tried to address in the last revision
> of the patch.
OK! I didn't see it here and I guess I didn't look at the latest version
yet, or I missed it.
> If you take a look at the top of new cfg80211_update_assoc_bss_entry
> function:
>
> + /* use transmitting bss */
> + if (cbss->pub.transmitted_bss)
> + cbss = container_of(cbss->pub.transmitted_bss,
> + struct cfg80211_internal_bss,
> + pub);
Right, makes sense!
> Actually one of the major concerns is the lack of testing for the 'multi-BSSID'
> scenario. I verified the 'normal' scenario using both mac80211 (iwlwifi) and
> FullMAC (qtnfmac) cards. But at the moment I don't have any mac80211 card
> supporting multi-BSSID.
You might be able to do that with hwsim? There are multi-bssid test
cases in the hostap repository, and CSA test cases as well, so I guess
it'd be possible to come up with a combined one.
I'm not *too* worried about this though - we're still all testing and
developing this.
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 2/2] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-26 12:04 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless@vger.kernel.org
Cc: Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190710173651.15770-3-sergey.matyukevich.os@quantenna.com>
Umm, regarding multi-BSSID, I'm clearly just not paying any attention
... sorry about that.
This looks good to me, can you resend as just PATCH?
Thanks,
johannes
^ permalink raw reply
* [RFC] mt76: fix tx hung regression on MT7630E
From: Stanislaw Gruszka @ 2019-07-26 12:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
I can observe firmware hangs on MT7630E on station mode: tx stop
functioning after minor activity (rx keep working) and on module
unload device fail to stop with messages:
[ 5446.141413] mt76x0e 0000:06:00.0: TX DMA did not stop
[ 5449.176764] mt76x0e 0000:06:00.0: TX DMA did not stop
Loading module again results in failure to associate with AP.
Only machine power off / power on cycle can make device work again.
I have no idea why the commit caused F/W hangs. Most likely some proper
fix is needed of changing registers programming (or assuring proper order
of actions), but so far I can not came up with any better fix than
a partial revert of 41634aa8d6db.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 5397827668b9..fefe0ee52584 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -598,7 +598,7 @@ void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
if (!test_bit(MT76_STATE_RUNNING, &dev->state))
return;
- tasklet_schedule(&dev->tx_tasklet);
+ mt76_txq_schedule(dev, txq->ac);
}
EXPORT_SYMBOL_GPL(mt76_wake_tx_queue);
--
1.9.3
^ permalink raw reply related
* Re: [RFC PATCH v3 2/2] cfg80211: fix duplicated scan entries after channel switch
From: Sergey Matyukevich @ 2019-07-26 12:30 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <92167a1803b9f90d231b080c9edfbf335c4685ed.camel@sipsolutions.net>
> Umm, regarding multi-BSSID, I'm clearly just not paying any attention
> ... sorry about that.
>
>
> This looks good to me, can you resend as just PATCH?
Sure, I will rebase on top of latest mac80211-next and resend.
Regards,
Sergey
^ permalink raw reply
* [PATCH v2 00/26] ReST conversion of text files without .txt extension
From: Mauro Carvalho Chehab @ 2019-07-26 12:51 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel, linux-pm,
linux-arm-kernel, linux-samsung-soc, linux-pci, linuxppc-dev,
linux-scsi, devicetree, linux-i2c, linux-hwmon, linux-spi,
linux-iio, linux-rtc, netdev, linux-parisc, openrisc, devel,
linux-cifs, samba-technical, devel, dmaengine, alsa-devel,
linux-mips, linux-wireless, rcu
This series converts the text files under Documentation with doesn't end
neither .txt or .rst and are not part of ABI or features.
This series is at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=rst_for_5_4_v3
And it is based on yesterday's upstream tree.
After this series, we have ~320 files left to be converted to ReST.
v2:
- Added 3 files submitted for v5.3 that weren't merged yet;
- markdown patch broken into two, per Rob's request;
- rebased on the top of upstream master branch
Mauro Carvalho Chehab (26):
docs: power: add it to to the main documentation index
docs: thermal: add it to the driver API
docs: powerpc: convert docs to ReST and rename to *.rst
docs: ubifs-authentication.md: convert to ReST
docs: writing-schema.md: convert from markdown to ReST
docs: i2c: convert to ReST and add to driver-api bookset
docs: w1: convert to ReST and add to the kAPI group of docs
spi: docs: convert to ReST and add it to the kABI bookset
docs: ipmb: place it at driver-api and convert to ReST
docs: packing: move it to core-api book and adjust markups
docs: admin-guide: add auxdisplay files to it after conversion to ReST
docs: README.buddha: convert to ReST and add to m68k book
docs: parisc: convert to ReST and add to documentation body
docs: openrisc: convert to ReST and add to documentation body
docs: isdn: convert to ReST and add to kAPI bookset
docs: fs: cifs: convert to ReST and add to admin-guide book
docs: fs: convert docs without extension to ReST
docs: fs: convert porting to ReST
docs: index.rst: don't use genindex for pdf output
docs: wimax: convert to ReST and add to admin-guide
docs: mips: add to the documentation body as ReST
docs: hwmon: pxe1610: convert to ReST format and add to the index
docs: nios2: add it to the main Documentation body
docs: net: convert two README files to ReST format
docs: rcu: convert some articles from html to ReST
docs: ABI: remove extension from sysfs-class-mic.txt
Documentation/ABI/stable/sysfs-bus-w1 | 2 +-
.../ABI/stable/sysfs-driver-w1_ds28e04 | 4 +-
.../ABI/stable/sysfs-driver-w1_ds28ea00 | 2 +-
.../{sysfs-class-mic.txt => sysfs-class-mic} | 0
Documentation/PCI/pci-error-recovery.rst | 2 +-
.../Data-Structures/Data-Structures.html | 1391 -------
.../Data-Structures/Data-Structures.rst | 1163 ++++++
...riods.html => Expedited-Grace-Periods.rst} | 949 ++---
.../Memory-Ordering/Tree-RCU-Diagram.html | 9 -
...ring.html => Tree-RCU-Memory-Ordering.rst} | 1181 +++---
.../RCU/Design/Requirements/Requirements.html | 3330 -----------------
.../RCU/Design/Requirements/Requirements.rst | 2662 +++++++++++++
Documentation/RCU/index.rst | 5 +
Documentation/RCU/whatisRCU.txt | 4 +-
.../auxdisplay/cfag12864b.rst} | 115 +-
.../admin-guide/auxdisplay/index.rst | 16 +
.../auxdisplay/ks0108.rst} | 53 +-
.../AUTHORS => admin-guide/cifs/authors.rst} | 64 +-
.../CHANGES => admin-guide/cifs/changes.rst} | 4 +
Documentation/admin-guide/cifs/index.rst | 21 +
.../cifs/introduction.rst} | 8 +
.../cifs/TODO => admin-guide/cifs/todo.rst} | 87 +-
.../README => admin-guide/cifs/usage.rst} | 560 +--
.../cifs/winucase_convert.pl | 0
Documentation/admin-guide/index.rst | 3 +
.../wimax/i2400m.rst} | 145 +-
Documentation/admin-guide/wimax/index.rst | 19 +
.../wimax/wimax.rst} | 36 +-
Documentation/core-api/index.rst | 3 +-
.../{packing.txt => core-api/packing.rst} | 81 +-
.../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 2 +-
.../{writing-schema.md => writing-schema.rst} | 137 +-
Documentation/driver-api/dmaengine/index.rst | 2 +-
Documentation/driver-api/index.rst | 2 +
Documentation/driver-api/ipmb.rst | 2 +-
Documentation/driver-api/soundwire/index.rst | 2 +-
.../thermal/cpu-cooling-api.rst | 0
.../thermal/exynos_thermal.rst | 0
.../thermal/exynos_thermal_emulation.rst | 0
.../{ => driver-api}/thermal/index.rst | 2 +-
.../thermal/intel_powerclamp.rst | 0
.../thermal/nouveau_thermal.rst | 0
.../thermal/power_allocator.rst | 0
.../{ => driver-api}/thermal/sysfs-api.rst | 12 +-
.../thermal/x86_pkg_temperature_thermal.rst | 2 +-
...irectory-locking => directory-locking.rst} | 40 +-
Documentation/filesystems/index.rst | 4 +
.../filesystems/{Locking => locking.rst} | 257 +-
.../nfs/{Exporting => exporting.rst} | 31 +-
.../filesystems/{porting => porting.rst} | 824 ++--
...entication.md => ubifs-authentication.rst} | 70 +-
Documentation/filesystems/vfs.rst | 2 +-
Documentation/hwmon/adm1021.rst | 2 +-
Documentation/hwmon/adm1275.rst | 2 +-
Documentation/hwmon/hih6130.rst | 2 +-
Documentation/hwmon/ibm-cffps.rst | 2 +-
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/lm25066.rst | 2 +-
Documentation/hwmon/max16064.rst | 2 +-
Documentation/hwmon/max16065.rst | 2 +-
Documentation/hwmon/max20751.rst | 2 +-
Documentation/hwmon/max34440.rst | 2 +-
Documentation/hwmon/max6650.rst | 2 +-
Documentation/hwmon/max8688.rst | 2 +-
Documentation/hwmon/menf21bmc.rst | 2 +-
Documentation/hwmon/pcf8591.rst | 2 +-
Documentation/hwmon/{pxe1610 => pxe1610.rst} | 33 +-
Documentation/hwmon/sht3x.rst | 2 +-
Documentation/hwmon/shtc1.rst | 2 +-
Documentation/hwmon/tmp103.rst | 2 +-
Documentation/hwmon/tps40422.rst | 2 +-
Documentation/hwmon/ucd9000.rst | 2 +-
Documentation/hwmon/ucd9200.rst | 2 +-
Documentation/hwmon/via686a.rst | 2 +-
Documentation/hwmon/zl6100.rst | 2 +-
.../busses/{i2c-ali1535 => i2c-ali1535.rst} | 13 +-
.../busses/{i2c-ali1563 => i2c-ali1563.rst} | 3 +
.../busses/{i2c-ali15x3 => i2c-ali15x3.rst} | 64 +-
.../busses/{i2c-amd-mp2 => i2c-amd-mp2.rst} | 14 +-
.../i2c/busses/{i2c-amd756 => i2c-amd756.rst} | 8 +-
.../busses/{i2c-amd8111 => i2c-amd8111.rst} | 14 +-
.../{i2c-diolan-u2c => i2c-diolan-u2c.rst} | 3 +
.../i2c/busses/{i2c-i801 => i2c-i801.rst} | 33 +-
.../i2c/busses/{i2c-ismt => i2c-ismt.rst} | 20 +-
.../busses/{i2c-mlxcpld => i2c-mlxcpld.rst} | 6 +
.../busses/{i2c-nforce2 => i2c-nforce2.rst} | 33 +-
.../{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} | 6 +-
.../i2c/busses/{i2c-ocores => i2c-ocores.rst} | 22 +-
...2c-parport-light => i2c-parport-light.rst} | 8 +-
.../busses/{i2c-parport => i2c-parport.rst} | 164 +-
.../busses/{i2c-pca-isa => i2c-pca-isa.rst} | 9 +-
.../i2c/busses/{i2c-piix4 => i2c-piix4.rst} | 18 +-
.../busses/{i2c-sis5595 => i2c-sis5595.rst} | 19 +-
.../i2c/busses/{i2c-sis630 => i2c-sis630.rst} | 39 +-
.../i2c/busses/{i2c-sis96x => i2c-sis96x.rst} | 31 +-
.../busses/{i2c-taos-evm => i2c-taos-evm.rst} | 8 +-
.../i2c/busses/{i2c-via => i2c-via.rst} | 28 +-
.../i2c/busses/{i2c-viapro => i2c-viapro.rst} | 12 +-
Documentation/i2c/busses/index.rst | 33 +
.../i2c/busses/{scx200_acb => scx200_acb.rst} | 9 +-
.../i2c/{dev-interface => dev-interface.rst} | 94 +-
...-considerations => dma-considerations.rst} | 0
.../i2c/{fault-codes => fault-codes.rst} | 5 +-
.../i2c/{functionality => functionality.rst} | 22 +-
...ult-injection => gpio-fault-injection.rst} | 12 +-
.../i2c/{i2c-protocol => i2c-protocol.rst} | 28 +-
Documentation/i2c/{i2c-stub => i2c-stub.rst} | 20 +-
.../i2c/{i2c-topology => i2c-topology.rst} | 68 +-
Documentation/i2c/index.rst | 37 +
...ting-devices => instantiating-devices.rst} | 45 +-
.../muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} | 26 +-
...e-parameters => old-module-parameters.rst} | 27 +-
...eprom-backend => slave-eeprom-backend.rst} | 4 +-
.../{slave-interface => slave-interface.rst} | 33 +-
.../{smbus-protocol => smbus-protocol.rst} | 86 +-
Documentation/i2c/{summary => summary.rst} | 6 +-
...en-bit-addresses => ten-bit-addresses.rst} | 5 +
...pgrading-clients => upgrading-clients.rst} | 204 +-
.../{writing-clients => writing-clients.rst} | 94 +-
Documentation/index.rst | 10 +
.../isdn/{README.avmb1 => avmb1.rst} | 231 +-
Documentation/isdn/{CREDITS => credits.rst} | 7 +-
.../isdn/{README.gigaset => gigaset.rst} | 290 +-
.../isdn/{README.hysdn => hysdn.rst} | 125 +-
Documentation/isdn/index.rst | 24 +
.../{INTERFACE.CAPI => interface_capi.rst} | 182 +-
.../isdn/{README.mISDN => m_isdn.rst} | 5 +-
.../m68k/{README.buddha => buddha-driver.rst} | 95 +-
Documentation/m68k/index.rst | 1 +
.../{AU1xxx_IDE.README => au1xxx_ide.rst} | 89 +-
Documentation/mips/index.rst | 17 +
.../networking/caif/{README => caif.rst} | 88 +-
.../networking/device_drivers/index.rst | 2 +-
Documentation/networking/index.rst | 2 +-
.../{README => mac80211_hwsim.rst} | 28 +-
Documentation/nios2/{README => nios2.rst} | 1 +
Documentation/openrisc/index.rst | 18 +
.../openrisc/{README => openrisc_port.rst} | 25 +-
Documentation/openrisc/{TODO => todo.rst} | 9 +-
.../parisc/{debugging => debugging.rst} | 7 +
Documentation/parisc/index.rst | 18 +
.../parisc/{registers => registers.rst} | 59 +-
Documentation/power/index.rst | 2 +-
.../{bootwrapper.txt => bootwrapper.rst} | 28 +-
.../{cpu_families.txt => cpu_families.rst} | 23 +-
.../{cpu_features.txt => cpu_features.rst} | 6 +-
Documentation/powerpc/{cxl.txt => cxl.rst} | 46 +-
.../powerpc/{cxlflash.txt => cxlflash.rst} | 10 +-
.../{DAWR-POWER9.txt => dawr-power9.rst} | 15 +-
Documentation/powerpc/{dscr.txt => dscr.rst} | 18 +-
...ecovery.txt => eeh-pci-error-recovery.rst} | 108 +-
...ed-dump.txt => firmware-assisted-dump.rst} | 117 +-
Documentation/powerpc/{hvcs.txt => hvcs.rst} | 108 +-
Documentation/powerpc/index.rst | 34 +
Documentation/powerpc/isa-versions.rst | 15 +-
.../powerpc/{mpc52xx.txt => mpc52xx.rst} | 12 +-
...nv.txt => pci_iov_resource_on_powernv.rst} | 15 +-
.../powerpc/{pmu-ebb.txt => pmu-ebb.rst} | 1 +
.../powerpc/{ptrace.txt => ptrace.rst} | 169 +-
.../{qe_firmware.txt => qe_firmware.rst} | 37 +-
.../{syscall64-abi.txt => syscall64-abi.rst} | 29 +-
...al_memory.txt => transactional_memory.rst} | 45 +-
Documentation/sound/index.rst | 2 +-
.../spi/{butterfly => butterfly.rst} | 44 +-
Documentation/spi/index.rst | 22 +
Documentation/spi/{pxa2xx => pxa2xx.rst} | 95 +-
.../spi/{spi-lm70llp => spi-lm70llp.rst} | 17 +-
.../spi/{spi-sc18is602 => spi-sc18is602.rst} | 5 +-
.../spi/{spi-summary => spi-summary.rst} | 105 +-
Documentation/spi/{spidev => spidev.rst} | 30 +-
Documentation/w1/index.rst | 21 +
.../w1/masters/{ds2482 => ds2482.rst} | 16 +-
.../w1/masters/{ds2490 => ds2490.rst} | 6 +-
Documentation/w1/masters/index.rst | 14 +
.../w1/masters/{mxc-w1 => mxc-w1.rst} | 13 +-
.../w1/masters/{omap-hdq => omap-hdq.rst} | 12 +-
.../w1/masters/{w1-gpio => w1-gpio.rst} | 21 +-
Documentation/w1/slaves/index.rst | 16 +
.../w1/slaves/{w1_ds2406 => w1_ds2406.rst} | 4 +-
.../w1/slaves/{w1_ds2413 => w1_ds2413.rst} | 9 +
.../w1/slaves/{w1_ds2423 => w1_ds2423.rst} | 27 +-
.../w1/slaves/{w1_ds2438 => w1_ds2438.rst} | 10 +-
.../w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} | 5 +
.../w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} | 16 +-
.../w1/slaves/{w1_therm => w1_therm.rst} | 11 +-
.../w1/{w1.generic => w1-generic.rst} | 88 +-
.../w1/{w1.netlink => w1-netlink.rst} | 89 +-
MAINTAINERS | 68 +-
arch/powerpc/kernel/exceptions-64s.S | 2 +-
drivers/auxdisplay/Kconfig | 2 +-
drivers/hwmon/atxp1.c | 2 +-
drivers/hwmon/smm665.c | 2 +-
drivers/i2c/Kconfig | 4 +-
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-i801.c | 2 +-
drivers/i2c/busses/i2c-taos-evm.c | 2 +-
drivers/i2c/i2c-core-base.c | 4 +-
drivers/iio/dummy/iio_simple_dummy.c | 4 +-
drivers/rtc/rtc-ds1374.c | 2 +-
drivers/soc/fsl/qe/qe.c | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-butterfly.c | 2 +-
drivers/spi/spi-lm70llp.c | 2 +-
drivers/staging/isdn/hysdn/Kconfig | 2 +-
drivers/tty/hvc/hvcs.c | 2 +-
fs/cifs/export.c | 2 +-
fs/exportfs/expfs.c | 2 +-
fs/isofs/export.c | 2 +-
fs/orangefs/file.c | 2 +-
fs/orangefs/orangefs-kernel.h | 2 +-
include/linux/dcache.h | 2 +-
include/linux/exportfs.h | 2 +-
include/linux/i2c.h | 2 +-
include/linux/platform_data/sc18is602.h | 2 +-
include/linux/thermal.h | 4 +-
include/soc/fsl/qe/qe.h | 2 +-
216 files changed, 9148 insertions(+), 8672 deletions(-)
rename Documentation/ABI/testing/{sysfs-class-mic.txt => sysfs-class-mic} (100%)
delete mode 100644 Documentation/RCU/Design/Data-Structures/Data-Structures.html
create mode 100644 Documentation/RCU/Design/Data-Structures/Data-Structures.rst
rename Documentation/RCU/Design/Expedited-Grace-Periods/{Expedited-Grace-Periods.html => Expedited-Grace-Periods.rst} (15%)
delete mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html
rename Documentation/RCU/Design/Memory-Ordering/{Tree-RCU-Memory-Ordering.html => Tree-RCU-Memory-Ordering.rst} (10%)
delete mode 100644 Documentation/RCU/Design/Requirements/Requirements.html
create mode 100644 Documentation/RCU/Design/Requirements/Requirements.rst
rename Documentation/{auxdisplay/cfag12864b => admin-guide/auxdisplay/cfag12864b.rst} (26%)
create mode 100644 Documentation/admin-guide/auxdisplay/index.rst
rename Documentation/{auxdisplay/ks0108 => admin-guide/auxdisplay/ks0108.rst} (32%)
rename Documentation/{filesystems/cifs/AUTHORS => admin-guide/cifs/authors.rst} (60%)
rename Documentation/{filesystems/cifs/CHANGES => admin-guide/cifs/changes.rst} (91%)
create mode 100644 Documentation/admin-guide/cifs/index.rst
rename Documentation/{filesystems/cifs/cifs.txt => admin-guide/cifs/introduction.rst} (98%)
rename Documentation/{filesystems/cifs/TODO => admin-guide/cifs/todo.rst} (58%)
rename Documentation/{filesystems/cifs/README => admin-guide/cifs/usage.rst} (72%)
rename Documentation/{filesystems => admin-guide}/cifs/winucase_convert.pl (100%)
rename Documentation/{wimax/README.i2400m => admin-guide/wimax/i2400m.rst} (69%)
create mode 100644 Documentation/admin-guide/wimax/index.rst
rename Documentation/{wimax/README.wimax => admin-guide/wimax/wimax.rst} (74%)
rename Documentation/{packing.txt => core-api/packing.rst} (61%)
rename Documentation/devicetree/{writing-schema.md => writing-schema.rst} (48%)
rename Documentation/{ => driver-api}/thermal/cpu-cooling-api.rst (100%)
rename Documentation/{ => driver-api}/thermal/exynos_thermal.rst (100%)
rename Documentation/{ => driver-api}/thermal/exynos_thermal_emulation.rst (100%)
rename Documentation/{ => driver-api}/thermal/index.rst (86%)
rename Documentation/{ => driver-api}/thermal/intel_powerclamp.rst (100%)
rename Documentation/{ => driver-api}/thermal/nouveau_thermal.rst (100%)
rename Documentation/{ => driver-api}/thermal/power_allocator.rst (100%)
rename Documentation/{ => driver-api}/thermal/sysfs-api.rst (98%)
rename Documentation/{ => driver-api}/thermal/x86_pkg_temperature_thermal.rst (94%)
rename Documentation/filesystems/{directory-locking => directory-locking.rst} (86%)
rename Documentation/filesystems/{Locking => locking.rst} (79%)
rename Documentation/filesystems/nfs/{Exporting => exporting.rst} (91%)
rename Documentation/filesystems/{porting => porting.rst} (49%)
rename Documentation/filesystems/{ubifs-authentication.md => ubifs-authentication.rst} (95%)
rename Documentation/hwmon/{pxe1610 => pxe1610.rst} (82%)
rename Documentation/i2c/busses/{i2c-ali1535 => i2c-ali1535.rst} (82%)
rename Documentation/i2c/busses/{i2c-ali1563 => i2c-ali1563.rst} (93%)
rename Documentation/i2c/busses/{i2c-ali15x3 => i2c-ali15x3.rst} (72%)
rename Documentation/i2c/busses/{i2c-amd-mp2 => i2c-amd-mp2.rst} (42%)
rename Documentation/i2c/busses/{i2c-amd756 => i2c-amd756.rst} (79%)
rename Documentation/i2c/busses/{i2c-amd8111 => i2c-amd8111.rst} (66%)
rename Documentation/i2c/busses/{i2c-diolan-u2c => i2c-diolan-u2c.rst} (91%)
rename Documentation/i2c/busses/{i2c-i801 => i2c-i801.rst} (89%)
rename Documentation/i2c/busses/{i2c-ismt => i2c-ismt.rst} (81%)
rename Documentation/i2c/busses/{i2c-mlxcpld => i2c-mlxcpld.rst} (88%)
rename Documentation/i2c/busses/{i2c-nforce2 => i2c-nforce2.rst} (58%)
rename Documentation/i2c/busses/{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} (63%)
rename Documentation/i2c/busses/{i2c-ocores => i2c-ocores.rst} (82%)
rename Documentation/i2c/busses/{i2c-parport-light => i2c-parport-light.rst} (91%)
rename Documentation/i2c/busses/{i2c-parport => i2c-parport.rst} (49%)
rename Documentation/i2c/busses/{i2c-pca-isa => i2c-pca-isa.rst} (72%)
rename Documentation/i2c/busses/{i2c-piix4 => i2c-piix4.rst} (92%)
rename Documentation/i2c/busses/{i2c-sis5595 => i2c-sis5595.rst} (74%)
rename Documentation/i2c/busses/{i2c-sis630 => i2c-sis630.rst} (37%)
rename Documentation/i2c/busses/{i2c-sis96x => i2c-sis96x.rst} (74%)
rename Documentation/i2c/busses/{i2c-taos-evm => i2c-taos-evm.rst} (91%)
rename Documentation/i2c/busses/{i2c-via => i2c-via.rst} (54%)
rename Documentation/i2c/busses/{i2c-viapro => i2c-viapro.rst} (87%)
create mode 100644 Documentation/i2c/busses/index.rst
rename Documentation/i2c/busses/{scx200_acb => scx200_acb.rst} (86%)
rename Documentation/i2c/{dev-interface => dev-interface.rst} (71%)
rename Documentation/i2c/{DMA-considerations => dma-considerations.rst} (100%)
rename Documentation/i2c/{fault-codes => fault-codes.rst} (98%)
rename Documentation/i2c/{functionality => functionality.rst} (91%)
rename Documentation/i2c/{gpio-fault-injection => gpio-fault-injection.rst} (97%)
rename Documentation/i2c/{i2c-protocol => i2c-protocol.rst} (83%)
rename Documentation/i2c/{i2c-stub => i2c-stub.rst} (93%)
rename Documentation/i2c/{i2c-topology => i2c-topology.rst} (89%)
create mode 100644 Documentation/i2c/index.rst
rename Documentation/i2c/{instantiating-devices => instantiating-devices.rst} (93%)
rename Documentation/i2c/muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} (85%)
rename Documentation/i2c/{old-module-parameters => old-module-parameters.rst} (75%)
rename Documentation/i2c/{slave-eeprom-backend => slave-eeprom-backend.rst} (90%)
rename Documentation/i2c/{slave-interface => slave-interface.rst} (94%)
rename Documentation/i2c/{smbus-protocol => smbus-protocol.rst} (82%)
rename Documentation/i2c/{summary => summary.rst} (96%)
rename Documentation/i2c/{ten-bit-addresses => ten-bit-addresses.rst} (95%)
rename Documentation/i2c/{upgrading-clients => upgrading-clients.rst} (54%)
rename Documentation/i2c/{writing-clients => writing-clients.rst} (91%)
rename Documentation/isdn/{README.avmb1 => avmb1.rst} (50%)
rename Documentation/isdn/{CREDITS => credits.rst} (96%)
rename Documentation/isdn/{README.gigaset => gigaset.rst} (74%)
rename Documentation/isdn/{README.hysdn => hysdn.rst} (80%)
create mode 100644 Documentation/isdn/index.rst
rename Documentation/isdn/{INTERFACE.CAPI => interface_capi.rst} (75%)
rename Documentation/isdn/{README.mISDN => m_isdn.rst} (89%)
rename Documentation/m68k/{README.buddha => buddha-driver.rst} (73%)
rename Documentation/mips/{AU1xxx_IDE.README => au1xxx_ide.rst} (67%)
create mode 100644 Documentation/mips/index.rst
rename Documentation/networking/caif/{README => caif.rst} (70%)
rename Documentation/networking/mac80211_hwsim/{README => mac80211_hwsim.rst} (81%)
rename Documentation/nios2/{README => nios2.rst} (96%)
create mode 100644 Documentation/openrisc/index.rst
rename Documentation/openrisc/{README => openrisc_port.rst} (80%)
rename Documentation/openrisc/{TODO => todo.rst} (78%)
rename Documentation/parisc/{debugging => debugging.rst} (94%)
create mode 100644 Documentation/parisc/index.rst
rename Documentation/parisc/{registers => registers.rst} (70%)
rename Documentation/powerpc/{bootwrapper.txt => bootwrapper.rst} (93%)
rename Documentation/powerpc/{cpu_families.txt => cpu_families.rst} (95%)
rename Documentation/powerpc/{cpu_features.txt => cpu_features.rst} (97%)
rename Documentation/powerpc/{cxl.txt => cxl.rst} (95%)
rename Documentation/powerpc/{cxlflash.txt => cxlflash.rst} (98%)
rename Documentation/powerpc/{DAWR-POWER9.txt => dawr-power9.rst} (95%)
rename Documentation/powerpc/{dscr.txt => dscr.rst} (91%)
rename Documentation/powerpc/{eeh-pci-error-recovery.txt => eeh-pci-error-recovery.rst} (82%)
rename Documentation/powerpc/{firmware-assisted-dump.txt => firmware-assisted-dump.rst} (80%)
rename Documentation/powerpc/{hvcs.txt => hvcs.rst} (91%)
create mode 100644 Documentation/powerpc/index.rst
rename Documentation/powerpc/{mpc52xx.txt => mpc52xx.rst} (91%)
rename Documentation/powerpc/{pci_iov_resource_on_powernv.txt => pci_iov_resource_on_powernv.rst} (97%)
rename Documentation/powerpc/{pmu-ebb.txt => pmu-ebb.rst} (99%)
rename Documentation/powerpc/{ptrace.txt => ptrace.rst} (48%)
rename Documentation/powerpc/{qe_firmware.txt => qe_firmware.rst} (95%)
rename Documentation/powerpc/{syscall64-abi.txt => syscall64-abi.rst} (82%)
rename Documentation/powerpc/{transactional_memory.txt => transactional_memory.rst} (93%)
rename Documentation/spi/{butterfly => butterfly.rst} (71%)
create mode 100644 Documentation/spi/index.rst
rename Documentation/spi/{pxa2xx => pxa2xx.rst} (83%)
rename Documentation/spi/{spi-lm70llp => spi-lm70llp.rst} (88%)
rename Documentation/spi/{spi-sc18is602 => spi-sc18is602.rst} (92%)
rename Documentation/spi/{spi-summary => spi-summary.rst} (93%)
rename Documentation/spi/{spidev => spidev.rst} (90%)
create mode 100644 Documentation/w1/index.rst
rename Documentation/w1/masters/{ds2482 => ds2482.rst} (71%)
rename Documentation/w1/masters/{ds2490 => ds2490.rst} (98%)
create mode 100644 Documentation/w1/masters/index.rst
rename Documentation/w1/masters/{mxc-w1 => mxc-w1.rst} (33%)
rename Documentation/w1/masters/{omap-hdq => omap-hdq.rst} (90%)
rename Documentation/w1/masters/{w1-gpio => w1-gpio.rst} (75%)
create mode 100644 Documentation/w1/slaves/index.rst
rename Documentation/w1/slaves/{w1_ds2406 => w1_ds2406.rst} (96%)
rename Documentation/w1/slaves/{w1_ds2413 => w1_ds2413.rst} (81%)
rename Documentation/w1/slaves/{w1_ds2423 => w1_ds2423.rst} (48%)
rename Documentation/w1/slaves/{w1_ds2438 => w1_ds2438.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} (88%)
rename Documentation/w1/slaves/{w1_therm => w1_therm.rst} (95%)
rename Documentation/w1/{w1.generic => w1-generic.rst} (59%)
rename Documentation/w1/{w1.netlink => w1-netlink.rst} (77%)
--
2.21.0
^ permalink raw reply
* [PATCH v2 24/26] docs: net: convert two README files to ReST format
From: Mauro Carvalho Chehab @ 2019-07-26 12:51 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, David S. Miller, Jonathan Corbet,
Johannes Berg, netdev, linux-doc, linux-wireless
In-Reply-To: <cover.1564145354.git.mchehab+samsung@kernel.org>
There are two README files there with doesn't have a .txt
extension nor are at ReST format.
In order to help with the docs conversion to ReST, rename those
and manually convert them to ReST format.
As there are lot more to be done for networking to be part of
the documentation body, for now mark those two files with
:orphan:, in order to supress a build warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../networking/caif/{README => caif.rst} | 88 +++++++++++++------
.../{README => mac80211_hwsim.rst} | 28 ++++--
MAINTAINERS | 2 +-
3 files changed, 81 insertions(+), 37 deletions(-)
rename Documentation/networking/caif/{README => caif.rst} (70%)
rename Documentation/networking/mac80211_hwsim/{README => mac80211_hwsim.rst} (81%)
diff --git a/Documentation/networking/caif/README b/Documentation/networking/caif/caif.rst
similarity index 70%
rename from Documentation/networking/caif/README
rename to Documentation/networking/caif/caif.rst
index 757ccfaa1385..07afc8063d4d 100644
--- a/Documentation/networking/caif/README
+++ b/Documentation/networking/caif/caif.rst
@@ -1,18 +1,31 @@
-Copyright (C) ST-Ericsson AB 2010
-Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
-License terms: GNU General Public License (GPL) version 2
----------------------------------------------------------
+:orphan:
-=== Start ===
-If you have compiled CAIF for modules do:
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
-$modprobe crc_ccitt
-$modprobe caif
-$modprobe caif_socket
-$modprobe chnl_net
+================
+Using Linux CAIF
+================
-=== Preparing the setup with a STE modem ===
+
+:Copyright: |copy| ST-Ericsson AB 2010
+
+:Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
+
+Start
+=====
+
+If you have compiled CAIF for modules do::
+
+ $modprobe crc_ccitt
+ $modprobe caif
+ $modprobe caif_socket
+ $modprobe chnl_net
+
+
+Preparing the setup with a STE modem
+====================================
If you are working on integration of CAIF you should make sure
that the kernel is built with module support.
@@ -32,24 +45,30 @@ module parameter "ser_use_stx".
Normally Frame Checksum is always used on UART, but this is also provided as a
module parameter "ser_use_fcs".
-$ modprobe caif_serial ser_ttyname=/dev/ttyS0 ser_use_stx=yes
-$ ifconfig caif_ttyS0 up
+::
-PLEASE NOTE: There is a limitation in Android shell.
+ $ modprobe caif_serial ser_ttyname=/dev/ttyS0 ser_use_stx=yes
+ $ ifconfig caif_ttyS0 up
+
+PLEASE NOTE:
+ There is a limitation in Android shell.
It only accepts one argument to insmod/modprobe!
-=== Trouble shooting ===
+Trouble shooting
+================
There are debugfs parameters provided for serial communication.
/sys/kernel/debug/caif_serial/<tty-name>/
* ser_state: Prints the bit-mask status where
+
- 0x02 means SENDING, this is a transient state.
- 0x10 means FLOW_OFF_SENT, i.e. the previous frame has not been sent
- and is blocking further send operation. Flow OFF has been propagated
- to all CAIF Channels using this TTY.
+ and is blocking further send operation. Flow OFF has been propagated
+ to all CAIF Channels using this TTY.
* tty_status: Prints the bit-mask tty status information
+
- 0x01 - tty->warned is on.
- 0x02 - tty->low_latency is on.
- 0x04 - tty->packed is on.
@@ -58,13 +77,17 @@ There are debugfs parameters provided for serial communication.
- 0x20 - tty->stopped is on.
* last_tx_msg: Binary blob Prints the last transmitted frame.
- This can be printed with
+
+ This can be printed with::
+
$od --format=x1 /sys/kernel/debug/caif_serial/<tty>/last_rx_msg.
- The first two tx messages sent look like this. Note: The initial
- byte 02 is start of frame extension (STX) used for re-syncing
- upon errors.
- - Enumeration:
+ The first two tx messages sent look like this. Note: The initial
+ byte 02 is start of frame extension (STX) used for re-syncing
+ upon errors.
+
+ - Enumeration::
+
0000000 02 05 00 00 03 01 d2 02
| | | | | |
STX(1) | | | |
@@ -73,7 +96,9 @@ There are debugfs parameters provided for serial communication.
Command:Enumeration(1)
Link-ID(1)
Checksum(2)
- - Channel Setup:
+
+ - Channel Setup::
+
0000000 02 07 00 00 00 21 a1 00 48 df
| | | | | | | |
STX(1) | | | | | |
@@ -86,13 +111,18 @@ There are debugfs parameters provided for serial communication.
Checksum(2)
* last_rx_msg: Prints the last transmitted frame.
- The RX messages for LinkSetup look almost identical but they have the
- bit 0x20 set in the command bit, and Channel Setup has added one byte
- before Checksum containing Channel ID.
- NOTE: Several CAIF Messages might be concatenated. The maximum debug
+
+ The RX messages for LinkSetup look almost identical but they have the
+ bit 0x20 set in the command bit, and Channel Setup has added one byte
+ before Checksum containing Channel ID.
+
+ NOTE:
+ Several CAIF Messages might be concatenated. The maximum debug
buffer size is 128 bytes.
-== Error Scenarios:
+Error Scenarios
+===============
+
- last_tx_msg contains channel setup message and last_rx_msg is empty ->
The host seems to be able to send over the UART, at least the CAIF ldisc get
notified that sending is completed.
@@ -103,7 +133,9 @@ There are debugfs parameters provided for serial communication.
- if /sys/kernel/debug/caif_serial/<tty>/tty_status is non-zero there
might be problems transmitting over UART.
+
E.g. host and modem wiring is not correct you will typically see
tty_status = 0x10 (hw_stopped) and ser_state = 0x10 (FLOW_OFF_SENT).
+
You will probably see the enumeration message in last_tx_message
and empty last_rx_message.
diff --git a/Documentation/networking/mac80211_hwsim/README b/Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
similarity index 81%
rename from Documentation/networking/mac80211_hwsim/README
rename to Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
index 3566a725d19c..d2266ce5534e 100644
--- a/Documentation/networking/mac80211_hwsim/README
+++ b/Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
@@ -1,5 +1,13 @@
+:orphan:
+
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===================================================================
mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211
-Copyright (c) 2008, Jouni Malinen <j@w1.fi>
+===================================================================
+
+:Copyright: |copy| 2008, Jouni Malinen <j@w1.fi>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
@@ -7,6 +15,7 @@ published by the Free Software Foundation.
Introduction
+============
mac80211_hwsim is a Linux kernel module that can be used to simulate
arbitrary number of IEEE 802.11 radios for mac80211. It can be used to
@@ -43,6 +52,7 @@ regardless of channel.
Simple example
+==============
This example shows how to use mac80211_hwsim to simulate two radios:
one to act as an access point and the other as a station that
@@ -50,17 +60,19 @@ associates with the AP. hostapd and wpa_supplicant are used to take
care of WPA2-PSK authentication. In addition, hostapd is also
processing access point side of association.
+::
-# Build mac80211_hwsim as part of kernel configuration
-# Load the module
-modprobe mac80211_hwsim
+ # Build mac80211_hwsim as part of kernel configuration
-# Run hostapd (AP) for wlan0
-hostapd hostapd.conf
+ # Load the module
+ modprobe mac80211_hwsim
-# Run wpa_supplicant (station) for wlan1
-wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf
+ # Run hostapd (AP) for wlan0
+ hostapd hostapd.conf
+
+ # Run wpa_supplicant (station) for wlan1
+ wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf
More test cases are available in hostap.git:
diff --git a/MAINTAINERS b/MAINTAINERS
index c7656edee696..4de2f288d1ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9568,7 +9568,7 @@ F: Documentation/networking/mac80211-injection.txt
F: include/net/mac80211.h
F: net/mac80211/
F: drivers/net/wireless/mac80211_hwsim.[ch]
-F: Documentation/networking/mac80211_hwsim/README
+F: Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
MAILBOX API
M: Jassi Brar <jassisinghbrar@gmail.com>
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 00/26] ReST conversion of text files without .txt extension
From: Mauro Carvalho Chehab @ 2019-07-26 13:05 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, linux-pm, linux-arm-kernel,
linux-samsung-soc, linux-pci, linuxppc-dev, linux-scsi,
devicetree, linux-i2c, linux-hwmon, linux-spi, linux-iio,
linux-rtc, netdev, linux-parisc, openrisc, devel, linux-cifs,
samba-technical, devel, dmaengine, alsa-devel, linux-mips,
linux-wireless, rcu
In-Reply-To: <cover.1564145354.git.mchehab+samsung@kernel.org>
Em Fri, 26 Jul 2019 09:51:10 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> This series converts the text files under Documentation with doesn't end
> neither .txt or .rst and are not part of ABI or features.
>
> This series is at:
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=rst_for_5_4_v3
>
> And it is based on yesterday's upstream tree.
>
> After this series, we have ~320 files left to be converted to ReST.
>
> v2:
> - Added 3 files submitted for v5.3 that weren't merged yet;
> - markdown patch broken into two, per Rob's request;
> - rebased on the top of upstream master branch
>
> Mauro Carvalho Chehab (26):
> docs: ABI: remove extension from sysfs-class-mic.txt
^ In time: this one was already merged.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Register support for HE meshpoint
From: Johannes Berg @ 2019-07-26 13:26 UTC (permalink / raw)
To: Sven Eckelmann, linux-wireless; +Cc: ath11k, Sven Eckelmann
In-Reply-To: <20190724163359.3507-3-sven@narfation.org>
On Wed, 2019-07-24 at 18:33 +0200, Sven Eckelmann wrote:
> From: Sven Eckelmann <seckelmann@datto.com>
>
> Some features of 802.11ax without central organizing (AP) STA can also be
> used in mesh mode. hwsim can be used to assist initial development of these
> features without having access to HW.
>
> Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
Even with the tshark workaround in place, this breaks 68 mesh-related
tests in hwsim tests. Jouni says only 3 use tshark ...
johannes
^ permalink raw reply
* Re: [PATCH v5 1/2] nl80211: Add support for EDMG channels
From: Johannes Berg @ 2019-07-26 13:29 UTC (permalink / raw)
To: Alexei Avshalom Lazar; +Cc: linux-wireless, wil6210
In-Reply-To: <1563194767-4817-2-git-send-email-ailizaro@codeaurora.org>
Hi Alexei,
I'm not exactly sure why, but this breaks practically all connectivity
on 2.4 and 5 GHz channels (at least in hwsim tests).
Please check and resubmit.
It'd also be good to reformat the commit log a bit, maybe adding
paragraphs, it's a bit of a "wall of text".
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Register support for HE meshpoint
From: Sven Eckelmann @ 2019-07-26 13:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath11k, Sven Eckelmann
In-Reply-To: <f2e16d10ce3eb3ff08c97c27424b824b8e012553.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
On Friday, 26 July 2019 15:26:32 CEST Johannes Berg wrote:
> On Wed, 2019-07-24 at 18:33 +0200, Sven Eckelmann wrote:
> > From: Sven Eckelmann <seckelmann@datto.com>
> >
> > Some features of 802.11ax without central organizing (AP) STA can also be
> > used in mesh mode. hwsim can be used to assist initial development of these
> > features without having access to HW.
> >
> > Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
>
> Even with the tshark workaround in place, this breaks 68 mesh-related
> tests in hwsim tests. Jouni says only 3 use tshark ...
As I already wrote:
> The first three things looks like wpa_supplicant problems. Seems to be
> caused by the way HE forces VHT to be enabled and now the tests fail
> which try to disable VHT. There was already a patch [0] for that but it
> wasn't considered a good solution.
> But beside these three things there are various other problems in
> > wpa_supplicant regarding HE with pending patches. So I've used
> wpa_supplicant 91b6eba7732354ed3dfe0aa9715dc4c0746e3336 with two
> additional patches [1,2] and increased the VM memory to 1024 MB. Also
> wireshark (tshark to be more precise) had to be updated to
> v3.1.0rc0-1192-gf64990438c
[...]
> [0] https://patchwork.ozlabs.org/patch/1125305/
> [1] https://patchwork.ozlabs.org/patch/1125314/
> [2] https://patchwork.ozlabs.org/patch/1125322/
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
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