* Re: [wireless-regdb] [PATCH] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)
From: Ryan Mounce @ 2017-10-19 23:18 UTC (permalink / raw)
To: Seth Forshee
Cc: wireless-regdb, linux-wireless,
Андрей Иванов
In-Reply-To: <20171019213834.23127-1-seth.forshee@canonical.com>
This is missing the DFS domain, which is almost certainly DFS-ETSI as
KZ is in ITU region 1.
Regards,
Ryan Mounce
On 20 October 2017 at 08:08, Seth Forshee <seth.forshee@canonical.com> wrote:
> Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> based on the documents at [1] and [2].
>
> [1] http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> [2] http://adilet.zan.kz/rus/docs/P000001379_
>
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> ---
> db.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/db.txt b/db.txt
> index e48f9a619651..96d8fda44284 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -689,8 +689,14 @@ country KY: DFS-FCC
> (5490 - 5730 @ 160), (24), DFS
> (5735 - 5835 @ 80), (30)
>
> +# Source:
> +# http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> +# http://adilet.zan.kz/rus/docs/P000001379_
> country KZ:
> (2402 - 2482 @ 40), (20)
> + (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
> + (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
> + (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
>
> country LB: DFS-FCC
> (2402 - 2482 @ 40), (20)
> --
> 2.14.1
>
>
> _______________________________________________
> wireless-regdb mailing list
> wireless-regdb@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wireless-regdb
^ permalink raw reply
* Re: [PATCH] wireless-regdb: add Short Range Devices (SRD) (ETSI EN 300 440) for Spain
From: Seth Forshee @ 2017-10-19 22:23 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, wireless-regdb
In-Reply-To: <20171015134637.2760-1-xose.vazquez@gmail.com>
On Sun, Oct 15, 2017 at 03:46:37PM +0200, Xose Vazquez Perez wrote:
> UN - 130 Dispositivos de corto alcance en 5 GHz :
> https://www.boe.es/buscar/act.php?id=BOE-A-2013-4845&tn=1&p=20150410
>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: wireless-regdb@lists.infradead.org
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)
From: Seth Forshee @ 2017-10-19 22:17 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: wireless-regdb, linux-wireless, simon.wunderlich
In-Reply-To: <20170926195445.4hqeixicrrohpsft@ubuntu-xps13>
On Tue, Sep 26, 2017 at 03:54:45PM -0400, Seth Forshee wrote:
> On Thu, Aug 24, 2017 at 11:17:44AM -0500, Seth Forshee wrote:
> > On Thu, Aug 24, 2017 at 09:13:42AM +0200, Sven Eckelmann wrote:
> > > On Mittwoch, 23. August 2017 15:52:40 CEST Seth Forshee wrote:
> > > [...]
> > > > > +# Source
> > > > > +# https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
> > > > > +# page 12-14
> > > > > +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented.
> > > [...]
> > > > > + # 5470 - 5725 is only allowed when TPC is implemented
> > > > > + # (5470 - 5725 @ 160), (30), DFS
> > > >
> > > > I'm not sure that the lack of a specific provision for operating without
> > > > TPC in this range means that it cannot be used. As I understand it, TPC
> > > > would only result in a reduction in EIRP of 3 dB, so as long as we use
> > > > a power limit of half of the maximum allowed we will be safe.
> > > >
> > > > If this is incorrect I'd appreciate it if someone more knowledgable on
> > > > the topic could chime in.
> > >
> > > I would also be happy about feedback regarding this part. But my current
> > > settings are based on the document [1] mentioned in this change.
> > >
> > > Let us look at the range 5250 – 5350 on page 13. There are two entries for the
> > > same frequency range.
> > >
> > > * 28:
> > > - up to 200 mW
> > > - requires TPC for 5250 – 5350 Mhz
> > > * 29:
> > > - up to 100 mW
> > > - requires *no* TPC for 5250 – 5350 Mhz
> > >
> > > This is exactly the 3(.01029995...) dB difference which you've talked about.
> > > Now to the frequency range 5470 - 5725 MHz on page 14.
> > >
> > > * 30:
> > > - up to 1000 mW
> > > - requires TPC for 5470 - 5725 MHz
> > >
> > > There is no extra exception rule for non-TPC mode.
> > >
> > > Now let us check what IEEE 802.11h-2003 [2] says about TPC.
> >
> > <snip detailed analysis>
> >
> > > My current change now assumes following strict interpretation:
> > >
> > > * Singapore provides a mitigation factor of 3 dB for 5250 – 5350 Mhz (see
> > > table entry 28 + 29)
> > > * Singapore provides now mitigation factor for 5470 - 5725 MHz and requires
> > > TPC
> > >
> > > I am currently unsure whether it is now valid to say that the default
> > > mitigation factor would be 3 dB and thus there is an implicit table entry (let
> > > us call it 30b) which would be:
> > >
> > > * 30b:
> > > - up to 500 mW
> > > - requires *no* TPC for 5470 - 5725 MHz
> > >
> > > Countries like AU or regions like ETSI (ETSI EN 301 893) seem to have this
> > > mitigation factor always specified in their rules. But Singapore is missing it
> > > for this specific frequency range.
> >
> > So on the one hand I'm in agreement, it would be good to know where the
> > 3 dB attenuation comes from and whether it's really universal. So far
> > it's been something I've taken on faith from folks a lot more familiar
> > with the subject than me.
> >
> > However, it seems the same lack of information would also anyone who
> > does want to support TPC. The information about how much to attenuate
> > must either be provided on a per-regulatory-domain basis or else it must
> > be standardized somehow. If it's the former then it seems odd that
> > Singapore does not include this information.
> >
> > Hopefully someone more knowledgable will chime in to help us understand
> > better.
>
> I was going through old messages in my inbox and realized that we've
> never done anything about this. Unless someone speaks up soon I guess
> I'll play it safe apply the patch as is, with the range commented out.
Applied, thanks!
^ permalink raw reply
* [PATCH] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)
From: Seth Forshee @ 2017-10-19 21:38 UTC (permalink / raw)
To: wireless-regdb, linux-wireless
Cc: Андрей Иванов
Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
based on the documents at [1] and [2].
[1] http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
[2] http://adilet.zan.kz/rus/docs/P000001379_
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
db.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/db.txt b/db.txt
index e48f9a619651..96d8fda44284 100644
--- a/db.txt
+++ b/db.txt
@@ -689,8 +689,14 @@ country KY: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+# Source:
+# http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
+# http://adilet.zan.kz/rus/docs/P000001379_
country KZ:
(2402 - 2482 @ 40), (20)
+ (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
+ (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
country LB: DFS-FCC
(2402 - 2482 @ 40), (20)
--
2.14.1
^ permalink raw reply related
* Re: wireless-regdb: Update regulatory rules for Kazakhstan (KZ) on 5GHz
From: Seth Forshee @ 2017-10-19 19:09 UTC (permalink / raw)
To: Андрей Иванов
Cc: wireless-regdb, linux-wireless
In-Reply-To: <1508432054.240009473@f105.i.mail.ru>
On Thu, Oct 19, 2017 at 07:54:14PM +0300, Андрей Иванов wrote:
> Hello again perirenal forums and laws of Kazakhstan on the 5GHz and everywhere one answer permitted use indoors frequency 5150-5350 and 5470-5725 MHz details there is no law painted as is done in other countries. Please add to this range in Kazakhstan is possible in the future and will develop in more detail the law on wi-fi 5 GHz, but currently it is what it is.
So, based on the doucment you linked to and one given earlier
(http://adilet.zan.kz/rus/docs/P000001379_) I'll send a paatch to allow
5150-5350 adn 5470-5725 MHz. However I think the power limit for all the
rules needs to be limited to 100mW instead of 1W as you had in some of
them, and we need to add the NO-OUTDOOR flag.
One of the documents also refers to ITU Resolution 229 with regard to
the 5GHz ranges, so I do think DFS is necessary in some of the ranges.
I'll follow up with a patch shortly.
> >Четверг, 19 октября 2017, 8:28 +06:00 от Андрей Иванов <wowz89@mail.ru>:
> >
> >Yes, I saw the frequencies wrong, but according to the documentation, you can add support for the frequencies 5150-5350 and 5470-5725 MHz, so that the phones on the Androyd started seeing Wi-fi 5GHz? or are our legislative acts not extinguishing you?
> >
> >I'm just not strong in all of your terms, but my phone does not see wi-fi 5GHz and with support we figured out that due to the fact that it does not exist in wireless-regdb it will not see it.
> >
> >
> >>Четверг, 19 октября 2017, 0:49 +06:00 от Seth Forshee < seth.forshee@canonical.com >:
> >>
> >>On Wed, Oct 18, 2017 at 07:44:54PM +0300, Андрей Иванов wrote:
> >>>
> >>> In accordance with the communications act ( in the attachment) official source the government website mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> >>> on page 16 in paragraph 23 outlines that we can use frequency 5150–5350МГц 5470-5725 MHz indoor. It's an official order approved by the government also exert its scan where you can see all the printing and painting reference on the Internet http://adilet.zan.kz/rus/origins/V1500010730
> >>
> >>Any reason you dropped the mailing lists from your reply?
> >>
> >>A few notes/questions:
> >>
> >>1. We'll need to add the NO-OUTDOOR flag to the 5150-5350 and 5470-5725
> >> MHz ranges.
> >>
> >>2. I don't see anything about using DFS in the ranges where you have
> >> that. It's not unreasonable that this would be required, but I'm
> >> wondering whether I'm missing that or if there's someplace else which
> >> specifies this is needed?
> >>
> >>3. I don't see anything about using frequencies above 5725 MHz.
> >>
> >>4. The regulatory db is for unlicensed spectrum only. I'm reading a
> >> google translation of the document so I'm having a hard time being
> >> sure of what it says, but I do see a lot of references to permits or
> >> licenses. Can the spectrum you're trying to add be used without
> >> obtaining a permit or license?
> >>
> >>Thanks,
> >>Seth
> >>
> >>>
> >>> >Среда, 18 октября 2017, 19:50 +06:00 от Seth Forshee < seth.forshee@canonical.com >:
> >>> >
> >>> >On Wed, Oct 18, 2017 at 02:26:17PM +0300, Андрей Иванов wrote:
> >>> >> Please add support for 5 GHz in Kazakhstan
> >>> >> (5170 - 5250 @ 80), (20), AUTO-BW
> >>> >> (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> >>> >> (5650 - 5730 @ 80), (30), DFS
> >>> >> (5735 - 5835 @ 80), (30)
> >>> >
> >>> >We got a very similar submission not that long ago, and I had some
> >>> >questions which were never answered.
> >>> >
> >>> > http://lists.infradead.org/pipermail/wireless-regdb/2017-August/001086.html
> >>> >
> >>> >That one provided a link to some documentation for Kazakhstan, but the
> >>> >information there seemed incomplete to me. Can you answer the questions
> >>> >I asked there, or provide a link to a more complete source of
> >>> >information for the regulations in Kazakhstan?
> >>> >
> >>> >Thanks,
> >>> >Seth
> >>>
> >>>
> >>> С уважением,
> >>> Андрей Ивaнoв
> >>
> >>
> >>
> >
> >
> >С уважением,
> >Андрей Ивaнoв
>
>
> С уважением,
> Андрей Ивaнoв
^ permalink raw reply
* [PATCH] ath10k: fix build errors with !CONFIG_PM
From: Brian Norris @ 2017-10-19 18:45 UTC (permalink / raw)
To: Kalle Valo
Cc: Ryan Hsu, Grant Grundler, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
Arnd Bergmann
In-Reply-To: <20171019171224.GA46096@google.com>
Build errors have been reported with CONFIG_PM=n:
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
declaration of function 'ath10k_pci_suspend'
[-Werror=implicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
declaration of function 'ath10k_pci_resume'
[-Werror=implicit-function-declaration]
These are caused by the combination of the following two commits:
6af1de2e4ec4 ("ath10k: mark PM functions as __maybe_unused")
96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but
disabled")
Both build fine on their own.
But now that ath10k_pci_pm_{suspend,resume}() is compiled
unconditionally, we should also compile ath10k_pci_{suspend,resume}()
unconditionally.
And drop the #ifdef around ath10k_pci_hif_{suspend,resume}() too; they
are trivial (empty), so we're not saving much space by compiling them
out. And the alternatives would be to sprinkle more __maybe_unused, or
spread the #ifdef's further.
Build tested with the following combinations:
CONFIG_PM=y && CONFIG_PM_SLEEP=y
CONFIG_PM=y && CONFIG_PM_SLEEP=n
CONFIG_PM=n
Fixes: 96378bd2c6cd ("ath10k: fix core PCI suspend when WoWLAN is supported but disabled")
Fixes: 096ad2a15fd8 ("Merge branch 'ath-next'")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
drivers/net/wireless/ath/ath10k/pci.c | 5 -----
1 file changed, 5 deletions(-)
On Thu, Oct 19, 2017 at 10:12:25AM -0700, Brian Norris wrote:
> The solution would seem to be either to kill the #ifdefs around
> ath10k_pci_{suspend,resume}() and friends (and use __maybe_unused
> instead, to further extend Arnd's patch), or else revert Arnd's stuff
> and go with CONFIG_PM_SLEEP everywhere, which would resolve the original
> warning (promoted to error) that Arnd was resolving.
>
> I can send out one of these if you'd like.
Here you go :)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index b18a9b690df4..d790ea20b95d 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2577,8 +2577,6 @@ void ath10k_pci_hif_power_down(struct ath10k *ar)
*/
}
-#ifdef CONFIG_PM
-
static int ath10k_pci_hif_suspend(struct ath10k *ar)
{
/* Nothing to do; the important stuff is in the driver suspend. */
@@ -2627,7 +2625,6 @@ static int ath10k_pci_resume(struct ath10k *ar)
return ret;
}
-#endif
static bool ath10k_pci_validate_cal(void *data, size_t size)
{
@@ -2782,10 +2779,8 @@ static const struct ath10k_hif_ops ath10k_pci_hif_ops = {
.power_down = ath10k_pci_hif_power_down,
.read32 = ath10k_pci_read32,
.write32 = ath10k_pci_write32,
-#ifdef CONFIG_PM
.suspend = ath10k_pci_hif_suspend,
.resume = ath10k_pci_hif_resume,
-#endif
.fetch_cal_eeprom = ath10k_pci_hif_fetch_cal_eeprom,
};
--
2.15.0.rc1.287.g2b38de12cc-goog
^ permalink raw reply related
* Re: ath10k: fix core PCI suspend when WoWLAN is supported but disabled
From: Brian Norris @ 2017-10-19 17:12 UTC (permalink / raw)
To: Kalle Valo
Cc: Ryan Hsu, Grant Grundler, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ath10k@lists.infradead.org,
Arnd Bergmann
In-Reply-To: <87vajbgqcz.fsf@kamboji.qca.qualcomm.com>
+ Arnd
On Thu, Oct 19, 2017 at 02:32:45PM +0000, Kalle Valo wrote:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
> > Brian Norris <briannorris@chromium.org> wrote:
> >
> >> For devices where the FW supports WoWLAN but user-space has not
> >> configured it, we don't do any PCI-specific suspend/resume operations,
> >> because mac80211 doesn't call drv_suspend() when !wowlan. This has
> >> particularly bad effects for some platforms, because we don't stop the
> >> power-save timer, and if this timer goes off after the PCI controller
> >> has suspended the link, Bad Things will happen.
> >>
> >> Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> >> got some of this right, in that it understood there was a problem on
> >> non-WoWLAN firmware. But it forgot the $subject case.
> >>
> >> Fix this by moving all the PCI driver suspend/resume logic exclusively
> >> into the driver PM hooks. This shouldn't affect WoWLAN support much
> >> (this just gets executed later on).
> >>
> >> I would just as well kill the entirety of ath10k_hif_suspend(), as it's
> >> not even implemented on the USB or SDIO drivers. I expect that we don't
> >> need the callback, except to return "supported" (i.e., 0) or "not
> >> supported" (i.e., -EOPNOTSUPP).
> >>
> >> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
> >> Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
> >> Signed-off-by: Brian Norris <briannorris@chromium.org>
> >> Cc: Ryan Hsu <ryanhsu@qti.qualcomm.com>
> >> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> >> Cc: Michal Kazior <michal.kazior@tieto.com>
> >> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
> >
> > Patch applied to ath-next branch of ath.git, thanks.
> >
> > 96378bd2c6cd ath10k: fix core PCI suspend when WoWLAN is supported but disabled
>
> Kbuild found a build problem, I suspect it's caused by this patch:
Actually, it's the interaction of this patch and Arnd's patch:
6af1de2e4ec4 ath10k: mark PM functions as __maybe_unused
I see that's now in these branches:
ath/ath-current
ath/ath-qca
ath/master
ath/master-pending
wireless-drivers-next/master
wireless-drivers-next/pending
Whereas mine got applied to:
ath/ath-next
So technically, the problem is in your merge here :)
096ad2a15fd8 Merge branch 'ath-next'
> drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
> declaration of function 'ath10k_pci_suspend'
> [-Werror=implicit-function-declaration]
>
> drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
> declaration of function 'ath10k_pci_resume'
> [-Werror=implicit-function-declaration]
>
> http://lists.infradead.org/pipermail/ath10k/2017-October/010269.html
>
> The .config.gz there doesn't have CONFIG_PM set, maybe that's the
> problem?
Yes, indirectly that's also the problem.
The solution would seem to be either to kill the #ifdefs around
ath10k_pci_{suspend,resume}() and friends (and use __maybe_unused
instead, to further extend Arnd's patch), or else revert Arnd's stuff
and go with CONFIG_PM_SLEEP everywhere, which would resolve the original
warning (promoted to error) that Arnd was resolving.
I can send out one of these if you'd like.
Brian
^ permalink raw reply
* wireless-regdb: Update regulatory rules for Kazakhstan (KZ) on 5GHz
From: Hiwow @ 2017-10-19 16:35 UTC (permalink / raw)
To: seth.forshee; +Cc: wireless-regdb, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
Hello, please add support frequencies for Kazakhstan's frequency range
(5150-5350 )
(5470-5725 )
I know in the law we have written about them not clearly but it is written that we can use these frequencies in the building of the building, there are no more detailed laws for us in the frequency of 5 GHz, as in other countries. But I ask you to be content with what we have.
[-- Attachment #2: Снимок.JPG --]
[-- Type: image/jpeg, Size: 75479 bytes --]
[-- Attachment #3: pravila_prisvoeniya_polos_chastot_no34.pdf --]
[-- Type: application/pdf, Size: 369515 bytes --]
^ permalink raw reply
* Re: ath10k: fix core PCI suspend when WoWLAN is supported but disabled
From: Kalle Valo @ 2017-10-19 14:32 UTC (permalink / raw)
To: Brian Norris
Cc: Ryan Hsu, Grant Grundler, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <2809b2cf512d4c198d3cef3f5e468c3c@euamsexm01e.eu.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Brian Norris <briannorris@chromium.org> wrote:
>
>> For devices where the FW supports WoWLAN but user-space has not
>> configured it, we don't do any PCI-specific suspend/resume operations,
>> because mac80211 doesn't call drv_suspend() when !wowlan. This has
>> particularly bad effects for some platforms, because we don't stop the
>> power-save timer, and if this timer goes off after the PCI controller
>> has suspended the link, Bad Things will happen.
>>=20
>> Commit 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
>> got some of this right, in that it understood there was a problem on
>> non-WoWLAN firmware. But it forgot the $subject case.
>>=20
>> Fix this by moving all the PCI driver suspend/resume logic exclusively
>> into the driver PM hooks. This shouldn't affect WoWLAN support much
>> (this just gets executed later on).
>>=20
>> I would just as well kill the entirety of ath10k_hif_suspend(), as it's
>> not even implemented on the USB or SDIO drivers. I expect that we don't
>> need the callback, except to return "supported" (i.e., 0) or "not
>> supported" (i.e., -EOPNOTSUPP).
>>=20
>> Fixes: 32faa3f0ee50 ("ath10k: add the PCI PM core suspend/resume ops")
>> Fixes: 77258d409ce4 ("ath10k: enable pci soc powersaving")
>> Signed-off-by: Brian Norris <briannorris@chromium.org>
>> Cc: Ryan Hsu <ryanhsu@qti.qualcomm.com>
>> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
>> Cc: Michal Kazior <michal.kazior@tieto.com>
>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>
> Patch applied to ath-next branch of ath.git, thanks.
>
> 96378bd2c6cd ath10k: fix core PCI suspend when WoWLAN is supported but di=
sabled
Kbuild found a build problem, I suspect it's caused by this patch:
drivers/net/wireless/ath/ath10k/pci.c:3416:8: error: implicit
declaration of function 'ath10k_pci_suspend'
[-Werror=3Dimplicit-function-declaration]
drivers/net/wireless/ath/ath10k/pci.c:3428:8: error: implicit
declaration of function 'ath10k_pci_resume'
[-Werror=3Dimplicit-function-declaration]
http://lists.infradead.org/pipermail/ath10k/2017-October/010269.html
The .config.gz there doesn't have CONFIG_PM set, maybe that's the
problem?
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] bcma: use bcma_debug and pr_cont in MIPS driver
From: Rafał Miłecki @ 2017-10-19 6:33 UTC (permalink / raw)
To: Joe Perches
Cc: Hauke Mehrtens, Rafał Miłecki, Kalle Valo,
linux-wireless
In-Reply-To: <1508377091.6806.32.camel@perches.com>
On 2017-10-19 03:38, Joe Perches wrote:
> On Mon, 2017-10-16 at 23:21 +0200, Hauke Mehrtens wrote:
>> On 10/16/2017 02:54 PM, Rafał Miłecki wrote:
>> > From: Rafał Miłecki <rafal@milecki.pl>
>> >
>> > Using bcma_debug gives a device-specific prefix for messages and pr_cont
>> > is a common helper for continuing a line.
>> >
>> > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>
>> Acked-By: Hauke Mehrtens <hauke@hauke-m.de>
>>
>> > ---
>> > drivers/bcma/driver_mips.c | 7 ++++---
>> > 1 file changed, 4 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
>> > index 89af807cf29c..5904ef1aa624 100644
>> > --- a/drivers/bcma/driver_mips.c
>> > +++ b/drivers/bcma/driver_mips.c
>> > @@ -184,10 +184,11 @@ static void bcma_core_mips_print_irq(struct bcma_device *dev, unsigned int irq)
>> > {
>> > int i;
>> > static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
>> > - printk(KERN_DEBUG KBUILD_MODNAME ": core 0x%04x, irq :", dev->id.id);
>> > +
>> > + bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
>> > for (i = 0; i <= 6; i++)
>> > - printk(" %s%s", irq_name[i], i == irq ? "*" : " ");
>> > - printk("\n");
>> > + pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
>> > + pr_cont("\n");
>> > }
>> >
>> > static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
>> >
>
> This isn't the same code as it depends on #define DEBUG
> and will not output the first line in most cases.
Oh, I didn't think about bcma_debug (pr_debug) being no_printk indeed.
AFAIU it will indeed make pr_cont default to the KERN_DEFAULT.
I'll try to test your code today or tomorrow, thanks!
^ permalink raw reply
* Re: [PATCH resend] brcmfmac: p2p and normal ap access are not always possible at the same time
From: Hans de Goede @ 2017-10-19 11:20 UTC (permalink / raw)
To: Arend van Spriel
Cc: Franky Lin, Hante Meuleman, Kalle Valo, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <90b34169-a2cd-6fbf-89e4-9b23e64f12c7@redhat.com>
Hi,
On 30-08-17 12:30, Hans de Goede wrote:
> Hi,
>
> On 30-08-17 12:24, Hans de Goede wrote:
>> Hi Arend,
>>
>> Sorry I was a bit slow to respond to this.
>>
>> On 04-08-17 14:35, Arend van Spriel wrote:
>>> On 5/26/2017 12:57 PM, Hans de Goede wrote:
>>>> The firmware responding with -EBUSY when trying to add an extra virtual-if
>>>> is a normal thing, do not print an error for this.
>>>
>>> Hi Hans,
>>>
>>> First of all, sorry! This one is long overdue (thanks for the reminder, Kalle). Not sure what the claim is here. I have to check the firmware to see what could make this fail. Thing is that wpa_supplicant will try to create the interface upon startup and it is really required for P2P operations. Now people not using that will probably not care about the failure, but I would like to find out why it is failing. wpa_supplicant will not do a retry upon -EBUSY.
>>>
>>> With which firmware (target string and version) are you seeing this so I know where to dive in.
>>
>> [root@localhost ~]# dmesg | grep brcm
>> [ 11.252078] brcmutil: loading out-of-tree module taints kernel.
>> [ 11.252159] brcmutil: module verification failed: signature and/or required key missing - tainting kernel
>> [ 11.484195] brcmfmac: brcmf_sdio_probe: Loading firmware brcm/brcmfmac43430a0-sdio.bin for chip 0000a9a6 rev 00000000
>> [ 11.484290] usbcore: registered new interface driver brcmfmac
>> [ 11.616053] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun 6 2014 14:50:39 version 7.10.226.49 (r) FWID 01-8962686a
>> [ 14.782464] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
>> [ 14.782488] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-16
>> [ 34.300531] brcmfmac: brcmf_p2p_create_p2pdev: set p2p_disc error
>> [ 34.300549] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-16
>>
>> [root@localhost ~]# strings /lib/firmware/brcm/brcmfmac43430a0-sdio.bin | tail -n 1
>> 43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-lpc-wl11u-rcc-fmc-wepso-ccx-okc-fbt-noccxaka-txpwr-ampduhostreorder-clm_43xx_lg Version: 7.10.226.49 CRC: bf92cb0b Date: Fri 2014-06-06 14:55:15 KST FWID 01-8962686a
>
> Since that firmware is quite old, I've tried again with a newer version:
>
> [ 11.219863] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 1 2016 18:02:40 version 7.10.1 (A0 Station/P2P feature) FWID 01-bae8afee
>
> [root@localhost ~]# strings /lib/firmware/brcm/brcmfmac43430a0-sdio.bin | tail -n 1
> 43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-lpc-wl11u-rcc-fmc-wepso-ccx-okc-fbt-noccxaka-txpwr-ampduhostreorder-clm_43xx_lg-ndoe Version: 7.10.1.244 CRC: 73c82137 Date: Fri 2016-07-01 18:03:15 KST Ucode Ver: 940.1020 FWID: 01-bae8afee
>
> Which still results in the same errors.
>
> Note this is with the a0 revision of the 43430 for which a firmware file is
> still missing from linux-firmware. If you happen to be able to add a file
> to linux-firmware while looking into this, that would be great.
Any update on this ? Since this does not seem to be going anywhere,
can we at least merge the harmless patch silencing the errors ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] wireless: iwlegacy: Convert timers to use timer_setup()
From: Stanislaw Gruszka @ 2017-10-19 8:54 UTC (permalink / raw)
To: Kees Cook; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171016233744.GA101655@beast>
On Mon, Oct 16, 2017 at 04:37:44PM -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Dmitry Vyukov @ 2017-10-19 8:25 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Andrey Konovalov, Helmut Schaa, Kalle Valo, linux-wireless,
netdev, LKML, Kostya Serebryany, syzkaller
In-Reply-To: <CACT4Y+YB7PTCFCjeqwJeGpSxxAh_U6F6UsDKaN4XAx6uL8+pZw@mail.gmail.com>
On Mon, Oct 16, 2017 at 2:19 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Oct 16, 2017 at 11:40 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> Hi Dmitry
>>
>> On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
>>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>> > Hi
>>> >
>>> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>>> >> I've got the following report while fuzzing the kernel with syzkaller.
>>> >>
>>> >> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>>> >>
>>> >> I'm not sure whether this is a bug in the driver, or just a way to
>>> >> report misbehaving device. In the latter case this shouldn't be a
>>> >> WARN() call, since WARN() means bug in the kernel.
>>> >
>>> > This is about wrong EEPROM, which reported 3 tx streams on
>>> > non 3 antenna device. I think WARN() is justified and thanks
>>> > to the call trace I was actually able to to understand what
>>> > happened.
>>> >
>>> > In general I do not think WARN() only means a kernel bug, it
>>> > can be F/W or H/W bug too.
>>>
>>> Hi Stanislaw,
>>>
>>> Printing messages is fine. Printing stacks is fine. Just please make
>>> them distinguishable from kernel bugs and don't kill the whole
>>> possibility of automated Linux kernel testing. That's an important
>>> capability.
>>
>> We do not distinguish between bugs and other problems when WARN() is
>> used in (wireless) drivers, what I think is correct, taking comment from
>> include/asm-generic/bug.h :
>>
>> /*
>> * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
>> * significant issues that need prompt attention if they should ever
>> * appear at runtime. Use the versions with printk format strings
>> * to provide better diagnostics.
>> */
>>
>> Historically we have BUG() to mark the bugs, but usage if it is not
>> recommended as it can kill the system, so for anything that can
>> be recovered in runtime - WARN() is recommended.
>>
>> Perhaps we can introduce another helper like PROBLEM() for marking
>> situations when something is wrong, but it is not a bug. However I'm
>> not even sure at what extent it can be used, since for many cases
>> if not the most, driver author can not tell apriori if the problem
>> is a bug in the driver or HW/FW misbehaviour (or maybe particular
>> issue can happen because of both).
>
> I will write a separate email to LKML.
Sent a mail titled "Distinguishing kernel bugs from invalid inputs" to
LKML. Here is a copy:
https://groups.google.com/forum/#!topic/syzkaller/dGh7qtbu14Q
^ permalink raw reply
* Re: [PATCH] wil6210: disallow changing RSN in beacon change
From: Lior David @ 2017-10-19 6:07 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Maya Erez, Jouni Malinen
In-Reply-To: <1508321623.2674.11.camel@sipsolutions.net>
On 10/18/2017 1:13 PM, Johannes Berg wrote:
....
>> hostapd uses change_beacon to change the security of the AP so this
>> needs to be supported.
>
> I didn't think this made sense - Jouni? Does hostapd kick off all
> stations in this case?
>
>> We do need to restart the AP in this case which will
>> disconnect existing clients, but this cannot be helped...
>
> Why not restart the AP entirely then from userspace? Hmm. I wonder what
> would happen with mac80211 - I guess keys would have to removed etc?
> Does this just work by accident because mac80211 removes the keys with
> stations? What about GTK(s) though?
>
Not sure what happens when the privacy stays the same (secure) but keys
change, maybe Jouni can comment.
>> As a side note, hostapd can also use change_beacon to change the
>> SSID.
>
> When does that happen?
By chance I worked on a WPS certification test last week which used
a shell script to perform various operations. The AP started secure
but the script could change its configuration to unsecure. It used
the wps_config CLI command to change both the security and
SSID and hostapd used change_beacon to perform this operation.
We got this script from WIFI team so there is good chance it
is in use by existing certification test beds.
^ permalink raw reply
* [PATCH V2] bcma: Use bcma_debug and not pr_cont in MIPS driver
From: Joe Perches @ 2017-10-19 5:45 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Hauke Mehrtens, Kalle Valo, linux-wireless, linux-kernel
Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
converted a printk(KERN_DEBUG to bcma_debug.
bcma_debug is guarded by a #define DEBUG via pr_debug.
This means that the bcma_debug will generally not be emitted
but any pr_cont following the bcma_debug will be emitted.
Correct this by removing the uses of pr_cont by using a temporary.
Signed-off-by: Joe Perches <joe@perches.com>
---
v2: Fix whitespace damage
I hear there's this checkpatch tool...
drivers/bcma/driver_mips.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 5904ef1aa624..f040aba48d50 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device *dev, unsigned int irq)
{
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
+ char interrupts[20];
+ char *ints = interrupts;
- bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
- for (i = 0; i <= 6; i++)
- pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
- pr_cont("\n");
+ for (i = 0; i < ARRAY_SIZE(irq_name); i++)
+ ints += sprintf(ints, " %s%c",
+ irq_name[i], i == irq ? '*' : ' ');
+
+ bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id, interrupts);
}
static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [PATCH] bcma: Use bcma_debug and not pr_cont in MIPS driver
From: James Cameron @ 2017-10-19 5:35 UTC (permalink / raw)
To: Joe Perches
Cc: Rafał Miłecki, Hauke Mehrtens, Kalle Valo,
linux-wireless, linux-kernel
In-Reply-To: <12998e0384c614c633148ea4dee48b95822d6425.1508389862.git.joe@perches.com>
On Wed, Oct 18, 2017 at 10:12:18PM -0700, Joe Perches wrote:
> Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
> converted a printk(KERN_DEBUG to bcma_debug.
>
> bcma_debug is guarded by a #define DEBUG via pr_debug.
>
> This means that the bcma_debug will generally not be emitted
> but any pr_cont following the bcma_debug will be emitted.
>
> Correct this by removing the uses of pr_cont by using a temporary.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/bcma/driver_mips.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index 5904ef1aa624..a929956150eb 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device *dev, unsigned int irq)
> {
> int i;
> static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> + char interrupts[20];
> + char *ints = interrupts;
Tabs were changed to spaces.
>
> - bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
> - for (i = 0; i <= 6; i++)
> - pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> - pr_cont("\n");
> + for (i = 0; i < ARRAY_SIZE(irq_name); i++)
> + ints += sprintf(ints, " %s%c",
> + irq_name[i], i == irq ? '*' : ' ');
But not on this line.
> +
> + bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id, interrupts);
> }
>
> static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> --
> 2.10.0.rc2.1.g053435c
>
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* [PATCH] bcma: Use bcma_debug and not pr_cont in MIPS driver
From: Joe Perches @ 2017-10-19 5:12 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Hauke Mehrtens, Kalle Valo, linux-wireless, linux-kernel
Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
converted a printk(KERN_DEBUG to bcma_debug.
bcma_debug is guarded by a #define DEBUG via pr_debug.
This means that the bcma_debug will generally not be emitted
but any pr_cont following the bcma_debug will be emitted.
Correct this by removing the uses of pr_cont by using a temporary.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/bcma/driver_mips.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index 5904ef1aa624..a929956150eb 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -184,11 +184,14 @@ static void bcma_core_mips_print_irq(struct bcma_device *dev, unsigned int irq)
{
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
+ char interrupts[20];
+ char *ints = interrupts;
- bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
- for (i = 0; i <= 6; i++)
- pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
- pr_cont("\n");
+ for (i = 0; i < ARRAY_SIZE(irq_name); i++)
+ ints += sprintf(ints, " %s%c",
+ irq_name[i], i == irq ? '*' : ' ');
+
+ bcma_debug(dev->bus, "core 0x%04x, irq:%s\n", dev->id.id, interrupts);
}
static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [PATCH] bcma: use bcma_debug and pr_cont in MIPS driver
From: Kalle Valo @ 2017-10-19 4:19 UTC (permalink / raw)
To: Joe Perches
Cc: Hauke Mehrtens, Rafał Miłecki, linux-wireless,
Rafał Miłecki
In-Reply-To: <1508377091.6806.32.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Mon, 2017-10-16 at 23:21 +0200, Hauke Mehrtens wrote:
>> On 10/16/2017 02:54 PM, Rafa=C5=82 Mi=C5=82ecki wrote:
>> > From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>> >=20
>> > Using bcma_debug gives a device-specific prefix for messages and pr_co=
nt
>> > is a common helper for continuing a line.
>> >=20
>> > Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>=20
>> Acked-By: Hauke Mehrtens <hauke@hauke-m.de>
>>=20
>> > ---
>> > drivers/bcma/driver_mips.c | 7 ++++---
>> > 1 file changed, 4 insertions(+), 3 deletions(-)
>> >=20
>> > diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
>> > index 89af807cf29c..5904ef1aa624 100644
>> > --- a/drivers/bcma/driver_mips.c
>> > +++ b/drivers/bcma/driver_mips.c
>> > @@ -184,10 +184,11 @@ static void bcma_core_mips_print_irq(struct bcma=
_device *dev, unsigned int irq)
>> > {
>> > int i;
>> > static const char *irq_name[] =3D {"2(S)", "3", "4", "5", "6", "D", =
"I"};
>> > - printk(KERN_DEBUG KBUILD_MODNAME ": core 0x%04x, irq :", dev->id.id);
>> > +
>> > + bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
>> > for (i =3D 0; i <=3D 6; i++)
>> > - printk(" %s%s", irq_name[i], i =3D=3D irq ? "*" : " ");
>> > - printk("\n");
>> > + pr_cont(" %s%s", irq_name[i], i =3D=3D irq ? "*" : " ");
>> > + pr_cont("\n");
>> > }
>> >=20=20
>> > static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
>> >=20
>
> This isn't the same code as it depends on #define DEBUG
> and will not output the first line in most cases.
>
> I'd suggest a nack.
Too late, I already applied this. Please submit a followup patch if
something needs to be changed.
--=20
Kalle Valo
^ permalink raw reply
* Re: rtlwifi oops
From: Larry Finger @ 2017-10-19 2:00 UTC (permalink / raw)
To: nirinA, James Cameron, linux-wireless
In-Reply-To: <b86480bd-49b9-f7ac-5dc5-6f6f83942727@gmail.com>
On 10/18/2017 08:40 PM, nirinA wrote:
> i checked my dmesg and have this similar log, i think when i unplugged the device.
>
> [ 5640.100541] usb 2-1.4: USB disconnect, device number 5
> [ 5640.104108] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed
> value=0x0
> [ 5640.104110] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut! status:0xffffffed
> value=0x0
> [ 5640.104113] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut! status:0xffffffed
> value=0x0
> [ 5640.104127] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut! status:0xffffffed
> value=0xd38000
>
> i will apply the patch and will see if i still get this.
As I said in the response to your private message:
No, that is a different error. You need to check for the USB disconnect when
starting, but no rtl_usb errors.
Larry
^ permalink raw reply
* Re: [PATCH] bcma: use bcma_debug and pr_cont in MIPS driver
From: Joe Perches @ 2017-10-19 1:38 UTC (permalink / raw)
To: Hauke Mehrtens, Rafał Miłecki, Kalle Valo,
linux-wireless
Cc: Rafał Miłecki
In-Reply-To: <50b62ff7-40c2-6980-27f8-4776b059800c@hauke-m.de>
On Mon, 2017-10-16 at 23:21 +0200, Hauke Mehrtens wrote:
> On 10/16/2017 02:54 PM, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal@milecki.pl>
> >
> > Using bcma_debug gives a device-specific prefix for messages and pr_cont
> > is a common helper for continuing a line.
> >
> > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>
> Acked-By: Hauke Mehrtens <hauke@hauke-m.de>
>
> > ---
> > drivers/bcma/driver_mips.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> > index 89af807cf29c..5904ef1aa624 100644
> > --- a/drivers/bcma/driver_mips.c
> > +++ b/drivers/bcma/driver_mips.c
> > @@ -184,10 +184,11 @@ static void bcma_core_mips_print_irq(struct bcma_device *dev, unsigned int irq)
> > {
> > int i;
> > static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> > - printk(KERN_DEBUG KBUILD_MODNAME ": core 0x%04x, irq :", dev->id.id);
> > +
> > + bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
> > for (i = 0; i <= 6; i++)
> > - printk(" %s%s", irq_name[i], i == irq ? "*" : " ");
> > - printk("\n");
> > + pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> > + pr_cont("\n");
> > }
> >
> > static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> >
This isn't the same code as it depends on #define DEBUG
and will not output the first line in most cases.
I'd suggest a nack.
Perhaps it'd be better to use a temporary and avoid the
pr_cont uses like:
{
int i;
static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
char interrupts[20];
char *ints = interrupts;
for (i = 0; i < ARRAY_SIZE(irq_name), i++)
ints += sprintf(ints, " %s%c", irq_name[i], i == irq ? '*' : ' ');
bcma_debug(dev->bus, "core 0x04x, irq: %s\n", dev->id.id, interrupts);
}
^ permalink raw reply
* Re: rtlwifi oops
From: nirinA @ 2017-10-19 1:40 UTC (permalink / raw)
To: James Cameron, linux-wireless
In-Reply-To: <fcf4b761-d7bd-7956-fa98-07fd8b2f8c3b@lwfinger.net>
i checked my dmesg and have this similar log, i think when i unplugged
the device.
[ 5640.100541] usb 2-1.4: USB disconnect, device number 5
[ 5640.104108] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0x0
[ 5640.104110] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0x0
[ 5640.104113] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0x0
[ 5640.104127] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0xd38000
i will apply the patch and will see if i still get this.
thanks,
--
nirinA Larry Finger wrote:
> On 10/18/2017 06:18 PM, nirinA wrote:
>> not really a rtlwifi oops then. maybe issue with udev as that also
>> disabled the usb mouse.
>> but i have no problem since. i will report if i will catch it again.
>>
>> thanks,
>>
>> --
>> nirinA
>>
>> James Cameron wrote:
>>> On Thu, Oct 19, 2017 at 01:31:43AM +0300, nirinA wrote:
>>>> hello there,
>>>> i got the oops below with a rtl8192cu:0bda:8178 and kernel 4.13.6, but
>>>> cannot reproduce it.
>>>> i use this device since 4.3 or so without noticing any issue.
>>>>
>>>> nirinA
>>>>
>>>> [ 239.338040] usb 2-1.3: new high-speed USB device number 4 using
>>>> ehci-pci
>>>> [ 239.417728] usb 2-1.3: New USB device found, idVendor=0bda,
>>>> idProduct=8178
>>>> [ 239.417730] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=3
>>>> [ 239.417731] usb 2-1.3: Product: 802.11n WLAN Adapter
>>>> [ 239.417732] usb 2-1.3: Manufacturer: Realtek
>>>> [ 239.417733] usb 2-1.3: SerialNumber: 00e04c000001
>>>> [ 239.578100] rtl8192cu: Chip version 0x11
>>>> [ 239.678225] usb 2-1-port3: disabled by hub (EMI?), re-enabling...
>>> Just prior to the oops, your USB hub disabled the port being used by
>>> the wireless device.
>>>
>>> While the response of the driver seems wrong, it is a difficult
>>> condition to reproduce; one must either force or forge the disabling
>>> by the hub.
>>>
>>>> [ 239.678230] usb 2-1.3: USB disconnect, device number 4
>>>> [ 239.679128] rtl_usb: reg 0x30, usbctrl_vendorreq TimeOut!
>>>> status:0xffffffed value=0x0
>
> This sequence of events is unusual. A driver should be able to trust
> that the platform is behaving correctly and normally.
>
> In reviewing the USB probe routine, the only thing I could see is that
> one returned value is not being checked. If the problem happens again,
> please try the following patch:
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
> b/drivers/net/wireless/realtek/rtlwifi/usb.c
> index 5590d07d0918..092cd2da15f6 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/usb.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
> @@ -1082,6 +1082,8 @@ int rtl_usb_probe(struct usb_interface *intf,
> init_completion(&rtlpriv->firmware_loading_complete);
> SET_IEEE80211_DEV(hw, &intf->dev);
> udev = interface_to_usbdev(intf);
> + if (!udev)
> + return -ENODEV;
> usb_get_dev(udev);
> usb_priv = rtl_usbpriv(hw);
> memset(usb_priv, 0, sizeof(*usb_priv));
>
> I will test and push this patch because that value should be checked,
> but I'm not sure it would correct your problem.
>
> Larry
>
>
>
^ permalink raw reply
* Re: rtlwifi oops
From: Larry Finger @ 2017-10-19 0:16 UTC (permalink / raw)
To: nirinA, James Cameron, linux-wireless
In-Reply-To: <c13aa975-6339-2f5a-20bb-0a82656a2271@gmail.com>
On 10/18/2017 06:18 PM, nirinA wrote:
> not really a rtlwifi oops then. maybe issue with udev as that also disabled the
> usb mouse.
> but i have no problem since. i will report if i will catch it again.
>
> thanks,
>
> --
> nirinA
>
> James Cameron wrote:
>> On Thu, Oct 19, 2017 at 01:31:43AM +0300, nirinA wrote:
>>> hello there,
>>> i got the oops below with a rtl8192cu:0bda:8178 and kernel 4.13.6, but
>>> cannot reproduce it.
>>> i use this device since 4.3 or so without noticing any issue.
>>>
>>> nirinA
>>>
>>> [ 239.338040] usb 2-1.3: new high-speed USB device number 4 using ehci-pci
>>> [ 239.417728] usb 2-1.3: New USB device found, idVendor=0bda,
>>> idProduct=8178
>>> [ 239.417730] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [ 239.417731] usb 2-1.3: Product: 802.11n WLAN Adapter
>>> [ 239.417732] usb 2-1.3: Manufacturer: Realtek
>>> [ 239.417733] usb 2-1.3: SerialNumber: 00e04c000001
>>> [ 239.578100] rtl8192cu: Chip version 0x11
>>> [ 239.678225] usb 2-1-port3: disabled by hub (EMI?), re-enabling...
>> Just prior to the oops, your USB hub disabled the port being used by
>> the wireless device.
>>
>> While the response of the driver seems wrong, it is a difficult
>> condition to reproduce; one must either force or forge the disabling
>> by the hub.
>>
>>> [ 239.678230] usb 2-1.3: USB disconnect, device number 4
>>> [ 239.679128] rtl_usb: reg 0x30, usbctrl_vendorreq TimeOut!
>>> status:0xffffffed value=0x0
This sequence of events is unusual. A driver should be able to trust that the
platform is behaving correctly and normally.
In reviewing the USB probe routine, the only thing I could see is that one
returned value is not being checked. If the problem happens again, please try
the following patch:
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 5590d07d0918..092cd2da15f6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1082,6 +1082,8 @@ int rtl_usb_probe(struct usb_interface *intf,
init_completion(&rtlpriv->firmware_loading_complete);
SET_IEEE80211_DEV(hw, &intf->dev);
udev = interface_to_usbdev(intf);
+ if (!udev)
+ return -ENODEV;
usb_get_dev(udev);
usb_priv = rtl_usbpriv(hw);
memset(usb_priv, 0, sizeof(*usb_priv));
I will test and push this patch because that value should be checked, but I'm
not sure it would correct your problem.
Larry
^ permalink raw reply related
* Re: [PATCH V6 0/5] Add TDLS feature for ath10k
From: Peter Oh @ 2017-10-18 23:37 UTC (permalink / raw)
To: yintang, ath10k; +Cc: linux-wireless
In-Reply-To: <1508133633-23214-1-git-send-email-yintang@qti.qualcomm.com>
On 10/15/2017 11:00 PM, yintang@qti.qualcomm.com wrote:
> From: Yingying Tang <yintang@qti.qualcomm.com>
>
> This patchset is for Rome PCIE chip, it will not affect other hardware
Please add your patchset history here until V6.
That's what cover letter is supposed to have.
> Yingying Tang (5):
> mac80211: Enable TDLS peer buffer STA feature
> ath10k: Enable TDLS peer buffer STA feature
> ath10k: Enable TDLS peer inactivity detection
> ath10k: Avoid to set WEP key for TDLS peer
> ath10k: Fix TDLS peer TX data failure issue on encryped AP
>
> drivers/net/wireless/ath/ath10k/mac.c | 9 ++++-
> drivers/net/wireless/ath/ath10k/wmi-tlv.c | 55 +++++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath10k/wmi-tlv.h | 9 +++++
> drivers/net/wireless/ath/ath10k/wmi.h | 1 +
> include/net/mac80211.h | 4 +++
> net/mac80211/tdls.c | 5 ++-
> 6 files changed, 81 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: rtlwifi oops
From: nirinA @ 2017-10-18 23:18 UTC (permalink / raw)
To: James Cameron, linux-wireless
In-Reply-To: <20171018223320.GB641@us.netrek.org>
not really a rtlwifi oops then. maybe issue with udev as that also
disabled the usb mouse.
but i have no problem since. i will report if i will catch it again.
thanks,
--
nirinA
James Cameron wrote:
> On Thu, Oct 19, 2017 at 01:31:43AM +0300, nirinA wrote:
>> hello there,
>> i got the oops below with a rtl8192cu:0bda:8178 and kernel 4.13.6, but
>> cannot reproduce it.
>> i use this device since 4.3 or so without noticing any issue.
>>
>> nirinA
>>
>> [ 239.338040] usb 2-1.3: new high-speed USB device number 4 using ehci-pci
>> [ 239.417728] usb 2-1.3: New USB device found, idVendor=0bda,
>> idProduct=8178
>> [ 239.417730] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [ 239.417731] usb 2-1.3: Product: 802.11n WLAN Adapter
>> [ 239.417732] usb 2-1.3: Manufacturer: Realtek
>> [ 239.417733] usb 2-1.3: SerialNumber: 00e04c000001
>> [ 239.578100] rtl8192cu: Chip version 0x11
>> [ 239.678225] usb 2-1-port3: disabled by hub (EMI?), re-enabling...
> Just prior to the oops, your USB hub disabled the port being used by
> the wireless device.
>
> While the response of the driver seems wrong, it is a difficult
> condition to reproduce; one must either force or forge the disabling
> by the hub.
>
>> [ 239.678230] usb 2-1.3: USB disconnect, device number 4
>> [ 239.679128] rtl_usb: reg 0x30, usbctrl_vendorreq TimeOut!
>> status:0xffffffed value=0x0
>> [ 239.679131] rtl_usb: reg 0x32, usbctrl_vendorreq TimeOut!
>> status:0xffffffed value=0x20
>> [ 239.679133] rtl_usb: reg 0x33, usbctrl_vendorreq TimeOut!
>> status:0xffffffed value=0x80
>> [ 239.679134] rtl_usb: reg 0x30, usbctrl_vendorreq TimeOut!
>> status:0xffffffed value=0x80206f30
>> [ 239.700640] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
>> [ 239.700648] BUG: unable to handle kernel NULL pointer dereference at
>> (null)
>> [ 239.700682] IP: rtl_deinit_core+0x2e/0x90 [rtlwifi]
>> [ 239.700693] PGD 1c5d5d067
>> [ 239.700694] P4D 1c5d5d067
>> [ 239.700701] PUD 1c5d9b067
>> [ 239.700708] PMD 0
>>
>> [ 239.700727] Oops: 0000 [#1] SMP
>> [ 239.700735] Modules linked in: rtl8192cu(+) rtl_usb rtl8192c_common
>> rtlwifi mac80211 cfg80211 rfkill appletalk ipx p8023 p8022 psnap llc nct6775
>> hwmon_vid ipv6 hid_generic usbhid hid coretemp hwmon x86_pkg_temp_thermal
>> intel_powerclamp snd_hda_codec_hdmi snd_hda_codec_realtek
>> snd_hda_codec_generic kvm_intel i915 kvm drm_kms_helper evdev i2c_dev
>> irqbypass syscopyarea sysfillrect sysimgblt r8169 crc32_pclmul serio_raw
>> crc32c_intel mii snd_pcsp fb_sys_fops drm fan thermal button battery 8250
>> 8250_base serial_core mei_me snd_hda_intel mei intel_gtt snd_hda_codec video
>> agpgart ehci_pci ehci_hcd lpc_ich snd_hwdep snd_hda_core snd_pcm
>> i2c_algo_bit snd_timer i2c_i801 i2c_core snd soundcore fuse
>> [ 239.700875] CPU: 0 PID: 1174 Comm: udevd Not tainted 4.13.6.20171012 #1
>> [ 239.700889] Hardware name: To be filled by O.E.M. To be filled by
>> O.E.M./ONDA H61V Ver:4.01, BIOS 4.6.5 01/07/2013
>> [ 239.700909] task: ffff8801c5fbc980 task.stack: ffffc900009a0000
>> [ 239.700924] RIP: 0010:rtl_deinit_core+0x2e/0x90 [rtlwifi]
>> [ 239.700936] RSP: 0000:ffffc900009a3b40 EFLAGS: 00010207
>> [ 239.700947] RAX: 0000000000000282 RBX: ffff8801b9440780 RCX:
>> 00000000ffffffea
>> [ 239.700962] RDX: 0000000000000001 RSI: 0000000000000282 RDI:
>> 0000000000000000
>> [ 239.700977] RBP: ffff8801b944b070 R08: 0000000000000001 R09:
>> 00000000000002b0
>> [ 239.700991] R10: ffffea0008473480 R11: 0000000000000000 R12:
>> ffff8801b9441560
>> [ 239.701006] R13: ffff8801b944b880 R14: 0000000000000000 R15:
>> ffff8801b9441560
>> [ 239.701021] FS: 00007f3eb636e7c0(0000) GS:ffff88021f200000(0000)
>> knlGS:0000000000000000
>> [ 239.701037] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 239.701050] CR2: 0000000000000000 CR3: 00000001c5d99000 CR4:
>> 00000000001406f0
>> [ 239.701064] Call Trace:
>> [ 239.701074] ? rtl_usb_probe+0x6b6/0xc50 [rtl_usb]
>> [ 239.701088] ? usb_probe_interface+0xe2/0x2a0
>> [ 239.701100] ? driver_probe_device+0x21d/0x2d0
>> [ 239.701111] ? __driver_attach+0x8a/0x90
>> [ 239.701121] ? driver_probe_device+0x2d0/0x2d0
>> [ 239.701133] ? bus_for_each_dev+0x5c/0x90
>> [ 239.701143] ? bus_add_driver+0x196/0x220
>> [ 239.701154] ? driver_register+0x57/0xc0
>> [ 239.701165] ? usb_register_driver+0x7c/0x140
>> [ 239.701175] ? 0xffffffffa064e000
>> [ 239.701185] ? do_one_initcall+0x4b/0x190
>> [ 239.701197] ? kmem_cache_alloc_trace+0xe4/0x1c0
>> [ 239.701208] ? do_init_module+0x22/0x1e1
>> [ 239.701219] ? do_init_module+0x5b/0x1e1
>> [ 239.701229] ? load_module+0x21ff/0x2760
>> [ 239.701239] ? SYSC_finit_module+0x90/0xb0
>> [ 239.701249] ? SYSC_finit_module+0x90/0xb0
>> [ 239.701261] ? entry_SYSCALL_64_fastpath+0x1a/0xa5
>> [ 239.701272] Code: 00 00 41 57 31 f6 41 56 41 55 41 54 55 53 48 89 fb e8
>> e7 fe ff ff 4c 8b 7b 48 49 8b bf 10 9b 00 00 49 8d af 10 9b 00 00 48 39 ef
>> <48> 8b 1f 74 44 49 bd 00 01 00 00 00 00 ad de 49 89 de 49 bc 00
>> [ 239.701327] RIP: rtl_deinit_core+0x2e/0x90 [rtlwifi] RSP:
>> ffffc900009a3b40
>> [ 239.702028] CR2: 0000000000000000
>> [ 239.705370] ---[ end trace 6ec9029c0d9c0e13 ]---
>> [ 239.706311] udevd[528]: worker [1174] failed while handling
>> '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0'
>>
^ permalink raw reply
* Re: [PATCH] staging: wilc1000: replace redundant computations with 0
From: Joe Perches @ 2017-10-18 22:54 UTC (permalink / raw)
To: Colin King, Aditya Shankar, Ganesh Krishna, Greg Kroah-Hartman,
linux-wireless, devel
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20171010140548.18016-1-colin.king@canonical.com>
On Tue, 2017-10-10 at 15:05 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Shifting and masking strHostIfSetMulti->enabled is redundant since
> enabled is a bool and so all the shifted and masked values will be
> zero. Replace them with zero to simplify the code.
>
> Detected by CoverityScan, CID#1339458 ("Bad shift operation") and
> CID#1339506 ("Operands don't affect result").
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/staging/wilc1000/host_interface.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
> index 7b620658ec38..94477dd08c85 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -2417,9 +2417,9 @@ static void Handle_SetMulticastFilter(struct wilc_vif *vif,
>
> pu8CurrByte = wid.val;
> *pu8CurrByte++ = (strHostIfSetMulti->enabled & 0xFF);
> - *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 8) & 0xFF);
> - *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 16) & 0xFF);
> - *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 24) & 0xFF);
> + *pu8CurrByte++ = 0;
> + *pu8CurrByte++ = 0;
> + *pu8CurrByte++ = 0;
This might be more an indication of another defect
Perhaps this is just supposed to be
*pu8CurrByte++ = strHostIfSetMulti->enabled;
without the three byte sets to zero after that.
> *pu8CurrByte++ = (strHostIfSetMulti->cnt & 0xFF);
> *pu8CurrByte++ = ((strHostIfSetMulti->cnt >> 8) & 0xFF);
^ 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