* Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
From: linux-wireless @ 2019-04-25 22:04 UTC (permalink / raw)
To: linux-wireless
Zdravstvuyte! Vas interesuyut kliyentskiye bazy dannykh?
^ permalink raw reply
* Re: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules for South Korea
From: Peter Oh @ 2019-04-25 22:14 UTC (permalink / raw)
To: b.K.il.h.u+tigbuh@gmail.com
Cc: linux-wireless@vger.kernel.org,
wireless-regdb@lists.infradead.org, Seth Forshee
In-Reply-To: <CAPuHQ=EMmq7M7HHAO8iMrOgsgn9dAg=siUWXQMc0sA_8t_kBAg@mail.gmail.com>
On 04/25/2019 01:37 PM, b.K.il.h.u+tigbuh@gmail.com wrote:
> Note that a link to the 2016-124 document is specified as reference in
> the above code (conversion also attached), not to 2016-125. Should we
> update the link? Although some of the numbers seem to match, the
> documents differ in structure and -125 seems to handle more bands.
I don't know where you downloaded 2016-124, but there is no link to
2016-124 one RAA website.
https://www.rra.go.kr/ko/reference/lawList_view.do?lw_seq=55&lw_type=3&searchCon=&lw_select=ALL&lw_model=&searchTxt=
Even though 2016-124 exist, we should refer 2016-125 since it's later
version than -124.
Thanks,
Peter
^ permalink raw reply
* Re: [wireless-regdb] wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: b.K.il.h.u+tigbuh @ 2019-04-25 22:01 UTC (permalink / raw)
To: seth.forshee; +Cc: junping.xu@jaguarwave.com, linux-wireless, wireless-regdb
In-Reply-To: <CAPuHQ=EvWzXtxk0fLOT6PyeYkcNOOXmw0ck-yT-JsqhhDmu2gA@mail.gmail.com>
P.S.: last link should have been
https://www.tuv.com/content-media-files/japan/pdfs/1190-telecom-and-radio-for-japan/1190-letter/60ghz2_1_19_4_2_1.pdf
On Fri, Apr 26, 2019 at 12:00 AM <b.K.il.h.u+tigbuh@gmail.com> wrote:
>
> This seems to be the page for the previous standard:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t74.html
>
> And the following should be the new standard, but I don't know where
> to obtain it:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t117.html
>
> The description fields here do note the range of 57-66GHz, though:
> https://www.arib.or.jp/kikaku/kikaku_tushin/desc/std-t117.html
> https://webstore.arib.or.jp/en/products/detail.php?product_id=288
>
> Similar mentions in the news (search for T117):
> https://www.arib.or.jp/image/osirase/news/1044.pdf
> https://www.arib.or.jp/image/iinkai/kikaku-kaigi/rireki/101.pdf
>
> Testing procedure is described here, not sure if it's considered useful:
> file:///home/bkil/chrome.root/Downloads/60ghz2_1_19_4_2_1.pdf
>
> On Mon, Apr 8, 2019 at 2:48 PM seth.forshee <seth.forshee@canonical.com> wrote:
> >
> > On Mon, Apr 01, 2019 at 06:07:44PM +0800, junping.xu@jaguarwave.com wrote:
> > > Hi Forsheee,
> > > The 60GHz band defined for Japan was between 59-66GHz, but is has been Updated to support 57-66Ghz about 2 years ago。
> > > However, the latest wireless-regdb still containning the original regulatory information as below. Please help to check the infomation
> > > and update the regulatory.bin.
> > >
> > > db.txt:
> > > ......
> > > country JP: DFS-JP
> > > (2402 - 2482 @ 40), (20)
> > > (2474 - 2494 @ 20), (20), NO-OFDM
> > > (4910 - 4990 @ 40), (23)
> > > (5030 - 5090 @ 40), (23)
> > > (5170 - 5250 @ 80), (20), AUTO-BW
> > > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > > (5490 - 5710 @ 160), (23), DFS
> > > # 60 GHz band channels 2-4 at 10mW,
> > > # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
> >
> > The only change which is required to change:
> >
> > > (59000 - 66000 @ 2160), (10 mW)
> >
> > to:
> >
> > (57000 - 66000 @ 2160), (10 mW)
> >
> > Is that right? Can you provide a link to the documentation which
> > supports this change? The current link above this rule appears to be
> > broken.
> >
> > Thanks,
> > Seth
> >
> > _______________________________________________
> > wireless-regdb mailing list
> > wireless-regdb@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/wireless-regdb
^ permalink raw reply
* Re: [wireless-regdb] wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: b.K.il.h.u+tigbuh @ 2019-04-25 22:00 UTC (permalink / raw)
To: seth.forshee; +Cc: junping.xu@jaguarwave.com, linux-wireless, wireless-regdb
In-Reply-To: <20190408124829.GD15126@ubuntu-xps13>
This seems to be the page for the previous standard:
https://www.arib.or.jp/english/std_tr/telecommunications/std-t74.html
And the following should be the new standard, but I don't know where
to obtain it:
https://www.arib.or.jp/english/std_tr/telecommunications/std-t117.html
The description fields here do note the range of 57-66GHz, though:
https://www.arib.or.jp/kikaku/kikaku_tushin/desc/std-t117.html
https://webstore.arib.or.jp/en/products/detail.php?product_id=288
Similar mentions in the news (search for T117):
https://www.arib.or.jp/image/osirase/news/1044.pdf
https://www.arib.or.jp/image/iinkai/kikaku-kaigi/rireki/101.pdf
Testing procedure is described here, not sure if it's considered useful:
file:///home/bkil/chrome.root/Downloads/60ghz2_1_19_4_2_1.pdf
On Mon, Apr 8, 2019 at 2:48 PM seth.forshee <seth.forshee@canonical.com> wrote:
>
> On Mon, Apr 01, 2019 at 06:07:44PM +0800, junping.xu@jaguarwave.com wrote:
> > Hi Forsheee,
> > The 60GHz band defined for Japan was between 59-66GHz, but is has been Updated to support 57-66Ghz about 2 years ago。
> > However, the latest wireless-regdb still containning the original regulatory information as below. Please help to check the infomation
> > and update the regulatory.bin.
> >
> > db.txt:
> > ......
> > country JP: DFS-JP
> > (2402 - 2482 @ 40), (20)
> > (2474 - 2494 @ 20), (20), NO-OFDM
> > (4910 - 4990 @ 40), (23)
> > (5030 - 5090 @ 40), (23)
> > (5170 - 5250 @ 80), (20), AUTO-BW
> > (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> > (5490 - 5710 @ 160), (23), DFS
> > # 60 GHz band channels 2-4 at 10mW,
> > # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
>
> The only change which is required to change:
>
> > (59000 - 66000 @ 2160), (10 mW)
>
> to:
>
> (57000 - 66000 @ 2160), (10 mW)
>
> Is that right? Can you provide a link to the documentation which
> supports this change? The current link above this rule appears to be
> broken.
>
> Thanks,
> Seth
>
> _______________________________________________
> wireless-regdb mailing list
> wireless-regdb@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wireless-regdb
^ permalink raw reply
* Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
From: Johannes Berg @ 2019-04-25 21:25 UTC (permalink / raw)
To: Arnd Bergmann, Al Viro
Cc: Mauro Carvalho Chehab, Linux FS-devel Mailing List,
y2038 Mailman List, Linux Kernel Mailing List, Jason Gunthorpe,
Daniel Vetter, Greg Kroah-Hartman, David Sterba, Darren Hart,
Jonathan Cameron, Bjorn Andersson, driverdevel, qat-linux,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
Linux Media Mailing List, dri-devel, linaro-mm-sig, amd-gfx,
open list:HID CORE LAYER, linux-iio, linux-rdma, linux-nvdimm,
linux-nvme, linux-pci, Platform Driver, linux-remoteproc,
sparclinux, linux-scsi, USB list, linux-btrfs, ceph-devel,
linux-wireless, Networking, Sean Young
In-Reply-To: <CAK8P3a2HmiYQJ2FV2FgLiFsD8M9UKteC9Jetx7ja06PQVZWYfA@mail.gmail.com>
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is not for s390, right?
> >
> > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > that thing works on all biarch architectures, as long as all stuff
> > handled by ->ioctl() takes pointer to arch-independent object as
> > argument. IOW,
> > argument ignored => OK
> > any arithmetical type => no go, compat_ptr() would bugger it
> > pointer to int => OK
> > pointer to string => OK
> > pointer to u64 => OK
> > pointer to struct {u64 addr; char s[11];} => OK
>
> To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> case is also broken on x86, because sizeof (obj) is smaller
> on i386, even though the location of the members are
> the same. i.e. you can copy_from_user() this
Actually, you can't even do that because the struct might sit at the end
of a page and then you'd erroneously fault in this case.
We had this a while ago with struct ifreq, see commit 98406133dd and its
parents.
johannes
^ permalink raw reply
* Re: [PATCH] mmc: dw_mmc: Disable SDIO interrupts while suspended to fix suspend/resume
From: Doug Anderson @ 2019-04-25 21:24 UTC (permalink / raw)
To: Emil Renner Berthing
Cc: Jaehoon Chung, Ulf Hansson, Shawn Lin, Heiko Stuebner,
Linux MMC List, Brian Norris, linux-wireless, stable,
Linux Kernel Mailing List, open list:ARM/Rockchip SoC...,
Matthias Kaehlcke, Ryan Case, Kalle Valo
In-Reply-To: <CANBLGcwmNowj9GSmE3bbo1t1o6EF8q-RiJftfdOQnJB9_8aSKg@mail.gmail.com>
Hi,
On Wed, Apr 24, 2019 at 1:19 AM Emil Renner Berthing
<emil.renner.berthing@gmail.com> wrote:
>
> Hi Douglas,
>
> Unfortunately this seems to beak resume on my rk3399-gru-kevin. I have
> a semi-complicated setup with my rootfs as a btrfs on dmcrypt on
> mmcblk0 which is the dw_mmc, so I'm guessing something goes wrong when
> waking up the dm_mmc which probably wasn't suspended before this
> patch. It's not 100% consistent though. Sometimes I see it resume the
> first time I try suspending, but then 2nd time I suspend it won't come
> back.
Thanks for testing!
Can you give me more details about your kernel version? Any local
patches? What config are you using?
I tried booting up my rk3388-gru-kevin on the Chrome OS 4.19 kernel (I
know, not quite fully upstream, but linuxnext just crashed upon boot
for me when I tried it). I have this patch in place and I booted from
SD card. I ran a Chrome OS tool which will test 20 cycles of
suspend/resume (uses the RTC to schedule a wakeup):
suspend_stress_test -c20 --suspend_min=15 --suspend_max=20
...and I didn't see failures.
...so I'm pretty baffled. On rk3399-gru-kevin you should have no SDIO
devices unless you've managed to cram an SDIO card into your micro SD
slot. Specifically WiFi is connected via PCIE.
As I wrote Shawn, I'm pretty sure my patch is a effectively a no-op in
these cases. "client_sdio_enb" should always be 0 and thus runtime
suspend and resume should just be:
spin_lock_irqsave(&host->irq_lock, irqflags);
int_mask = mci_readl(host, INTMASK);
mci_writel(host, INTMASK, int_mask);
spin_unlock_irqrestore(&host->irq_lock, irqflags);
...other than changing the timing slightly that shouldn't do anything at all.
My first guess is that this patch is your (un)lucky shirt, as in
"every time I wear my lucky shirt I win at slots in Las Vegas". Since
the problem you're seeing doesn't happen every time I'm going to guess
that you got lucky in that it seemed to go away when you reverted my
patch.
> Let me know if I can do something to help debug this.
Assuming the failure and this patch aren't just correlated by luck...
Logs would be a start. If you don't have serial console then
hopefully you've got console-ramoops working? Then if it's wedged you
can do the warmest reset you can (Alt-topRowVolUp-R) and hopefully the
ramoops will give you some logs.
Presumably you could also add some logs to double-check that all my
assertions are true. That is:
1. host->client_sdio_enb should always be false in __dw_mci_enable_sdio_irq()
2. In __dw_mci_enable_sdio_irq() confirm that the int_mask we are
writing is the same as the one we're reading. AKA the "if (enb) ...
else ..." makes no change to the value of int_mask.
Assuming my assertions are correct then pretty much everything is
_supposed_ to be a no-op on your system, so you can start gutting
things one at a time and see when the problem goes away:
a) Delete the call from suspend. Does it fix it?
b) Delete the call from resume. Does it fix it?
c) Delete parts of __dw_mci_enable_sdio_irq(). Get rid of the
mci_wirtel(). Does it fix it? What about if you get rid of the read
and the write and just have the spinlock?
===
If I can help with real-time debugging let me know. I'm in California
time zone and can be found as dianders in the #linux-rockchip channel
on freenode.
-Doug
^ permalink raw reply
* Re: [wireless-regdb] [PATCH] wireless-regdb: Update regulatory rules for South Korea
From: b.K.il.h.u+tigbuh @ 2019-04-25 20:37 UTC (permalink / raw)
To: Peter Oh
Cc: linux-wireless@vger.kernel.org,
wireless-regdb@lists.infradead.org, Seth Forshee
In-Reply-To: <b7af6387-a8bf-dfa0-b347-e58133d7298d@bowerswilkins.com>
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
Thank you for the information.
I could also successfully download 2016-125*2016.11.30*.hwp from here:
https://www.rra.go.kr/ko/reference/lawList_view.do?lw_seq=55&lw_type=3&searchCon=&lw_select=ALL&lw_model=&searchTxt=
And then convert it using this online tool:
https://appzend.herokuapp.com/hwpviewer/
It resulted in an HTML where copy&pasting also works (attached).
Translation of sections of interest are straight forward using an
online translator, like:
https://www.bing.com/translator
I haven't read through the document thoroughly yet, but I found
similar data to the table attached above below the section titled:
"주파수대역, 전력밀도 등"
Note that a link to the 2016-124 document is specified as reference in
the above code (conversion also attached), not to 2016-125. Should we
update the link? Although some of the numbers seem to match, the
documents differ in structure and -125 seems to handle more bands.
I do recommend that someone gives a second look into the numbers, as
some of the frequency ranges seem to have been extended as well. For
example, both this table and the document mentions:
2400-2483.5 instead of 2402-2482,
5150-5250 instead of 5170-5250,
5470-5725 instead of 5490-5710 and
5725-5850 instead of 5735-5835.
On Wed, Apr 24, 2019 at 7:33 PM Peter Oh <peter.oh@bowerswilkins.com> wrote:
>
>
>
> On 04/23/2019 01:54 PM, b.K.il.h.u+tigbuh@gmail.com wrote:
> > Could you please convert the document in question to a more open
> > format so we could try machine translation on it? ODT, HTML, docx and
> > PDF would probably work as long as copy & pasting is enabled.
> Please find attachment for converted one to PDF and also summary of
> power density.
> The spec for 2.4GHz and 5GHz devices are addressed in page 18, 19, 24
> and 25.
> (Page 26 is for non-DSSS modulation).
>
> Thanks,
> Peter
>
>
[-- Attachment #2: 27._2016-124__2016.11.30.hwp.zip --]
[-- Type: application/zip, Size: 16808 bytes --]
[-- Attachment #3: 2016-125__2016.11.30.hwp.zip --]
[-- Type: application/zip, Size: 48682 bytes --]
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-04-25 20:22 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425200830.GD58719@gmail.com>
On Thu, Apr 25, 2019 at 10:08:30PM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
> > >
> > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > >
> > > > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > > > >
> > > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > > >
> > > > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > > > When the bit is 0, split lock detection is not supported.
> > > > > >
> > > > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > > > Developer's Manual for more detailed information on the MSR and the
> > > > > > split lock detection bit.
> > > > > >
> > > > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > > > ---
> > > > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > > > 1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > > > --- a/arch/x86/include/asm/msr-index.h
> > > > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > > > @@ -59,6 +59,9 @@
> > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > > > >
> > > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > > > >
> > > > > Please don't put comments into definitions.
> > > >
> > > > I'll remove the comment and change definitions of the MSR and the split lock
> > > > detection bit as following:
> > > >
> > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> > > >
> > > > Are these right changes?
> > >
> > > I suspect it could be shortened to CORE_CAP as you (partly) did it
> > > originally.
> >
> > IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
> > https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
> >
> > So can I define the MSR and the bits as follows?
> >
> > +#define MSR_IA32_CORE_CAP 0x000000cf
> > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
> > +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
>
> Yeah, I suppose that looks OK.
Should I also change the feature definition 'X86_FEATURE_CORE_CAPABILITY' to
'X86_FEATURE_CORE_CAP' in cpufeatures.h in patch #0006 to match the
MSR definition here? Or should I still keep the current feature definition?
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Ingo Molnar @ 2019-04-25 20:08 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425195154.GC64477@romley-ivt3.sc.intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
> >
> > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> >
> > > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > > >
> > > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > > >
> > > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > > When the bit is 0, split lock detection is not supported.
> > > > >
> > > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > > Developer's Manual for more detailed information on the MSR and the
> > > > > split lock detection bit.
> > > > >
> > > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > > ---
> > > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > > --- a/arch/x86/include/asm/msr-index.h
> > > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > > @@ -59,6 +59,9 @@
> > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > > >
> > > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > > >
> > > > Please don't put comments into definitions.
> > >
> > > I'll remove the comment and change definitions of the MSR and the split lock
> > > detection bit as following:
> > >
> > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> > >
> > > Are these right changes?
> >
> > I suspect it could be shortened to CORE_CAP as you (partly) did it
> > originally.
>
> IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
> https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
>
> So can I define the MSR and the bits as follows?
>
> +#define MSR_IA32_CORE_CAP 0x000000cf
> +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
> +#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
Yeah, I suppose that looks OK.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-04-25 19:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425194714.GA58719@gmail.com>
On Thu, Apr 25, 2019 at 09:47:14PM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> > >
> > > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> > >
> > > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > > When the bit is 0, split lock detection is not supported.
> > > >
> > > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > > Developer's Manual for more detailed information on the MSR and the
> > > > split lock detection bit.
> > > >
> > > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > > ---
> > > > arch/x86/include/asm/msr-index.h | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > > --- a/arch/x86/include/asm/msr-index.h
> > > > +++ b/arch/x86/include/asm/msr-index.h
> > > > @@ -59,6 +59,9 @@
> > > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > > >
> > > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> > >
> > > Please don't put comments into definitions.
> >
> > I'll remove the comment and change definitions of the MSR and the split lock
> > detection bit as following:
> >
> > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> > +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
> >
> > Are these right changes?
>
> I suspect it could be shortened to CORE_CAP as you (partly) did it
> originally.
IA32_CORE_CAPABILITY is the MSR's exact name in the latest SDM (in Table 2-14):
https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
So can I define the MSR and the bits as follows?
+#define MSR_IA32_CORE_CAP 0x000000cf
+#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT 5
+#define MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAP_SPLIT_LOCK_DETECT_BIT)
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 09/15] x86/split_lock: Define MSR TEST_CTL register
From: Fenghua Yu @ 2019-04-25 19:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425062126.GC40105@gmail.com>
On Thu, Apr 25, 2019 at 08:21:26AM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > Setting bit 29 in MSR TEST_CTL (0x33) enables split lock detection and
> > clearing the bit disables split lock detection.
> >
> > Define the MSR and the bit. The definitions will be used in enabling or
> > disabling split lock detection.
> >
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > ---
> > arch/x86/include/asm/msr-index.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > index f65ef6f783d2..296eeb761ab6 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -39,6 +39,10 @@
> >
> > /* Intel MSRs. Some also available on other CPUs */
> >
> > +#define MSR_TEST_CTL 0x00000033
> > +#define TEST_CTL_SPLIT_LOCK_DETECT_SHIFT 29
> > +#define TEST_CTL_SPLIT_LOCK_DETECT BIT(29)
>
> Three problems:
>
> - Is MSR_TEST_CTL is not really a canonical MSR name... A quick look at
> msr-index reveals the prevailing nomenclature:
>
> dagon:~/tip> git grep -h 'define MSR' arch/x86/include/asm/msr-index.h | cut -d_ -f1-2 | sort -n | uniq -c | sort -n | tail -10
> 8 #define MSR_K8
> 8 #define MSR_MTRRfix4K
> 12 #define MSR_CORE
> 13 #define MSR_IDT
> 14 #define MSR_K7
> 16 #define MSR_PKG
> 19 #define MSR_F15H
> 33 #define MSR_AMD64
> 83 #define MSR_P4
> 163 #define MSR_IA32
>
> I.e. this shouldn't this be something like MSR_IA32_TEST_CTL - or this
> the name the Intel SDM uses? (I haven't checked.)
TEST_CTL is the MSR's exact name shown in Table 2-14 in the latest SDM.
https://software.intel.com/en-us/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4
So can I still use MSR_TEST_CTL here?
>
> - The canonical way to define MSR capabilities is to use the MSR's name
> as a prefix. I.e.:
>
> MSR_TEST_CTL
> MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT
> MSR_TEST_CTL_SPLIT_LOCK_DETECT
> etc.
>
> Instead of the random mixture of MSR_ prefixed and non-prefixed
> MSR_TEST_CTL, TEST_CTL_SPLIT_LOCK_DETECT_SHIFT and
> TEST_CTL_SPLIT_LOCK_DETECT names.
>
> - Finally, this is not how we define bits - the _SHIFT postfix is actively
> confusing as we usually denote _SHIFT values with something that is
> used in a bit-shift operation, which this isn't. Instead the proper
> scheme is to postfix the bit number with _BIT and the mask with _MASK,
> i.e. something like:
>
> #define MSR_TEST_CTL 0x00000033
> #define MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT 29
> #define MSR_TEST_CTL_SPLIT_LOCK_DETECT BIT(MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT)
>
> Note how this cleans up actual usage:
>
> + msr_set_bit(MSR_TEST_CTL, TEST_CTL_SPLIT_LOCK_DETECT_SHIFT);
> + this_cpu_or(msr_test_ctl_cache, TEST_CTL_SPLIT_LOCK_DETECT);
>
> - msr_set_bit(MSR_TEST_CTL, MSR_TEST_CTL_SPLIT_LOCK_DETECT_BIT);
> - this_cpu_or(msr_test_ctl_cache, MSR_TEST_CTL_SPLIT_LOCK_DETECT);
>
> Frankly, this kind of disorganized code in a v8 submission is *really*
> disappointing, it's not like it's hard to look up these patterns and
> practices in existing code...
OK. Will change the bit and mask definitions.
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Ingo Molnar @ 2019-04-25 19:47 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425190148.GA64477@romley-ivt3.sc.intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
> >
> > * Fenghua Yu <fenghua.yu@intel.com> wrote:
> >
> > > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > > enumerates a model specific feature. Currently bit 5 enumerates split
> > > lock detection. When bit 5 is 1, split lock detection is supported.
> > > When the bit is 0, split lock detection is not supported.
> > >
> > > Please check the latest Intel 64 and IA-32 Architectures Software
> > > Developer's Manual for more detailed information on the MSR and the
> > > split lock detection bit.
> > >
> > > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > > ---
> > > arch/x86/include/asm/msr-index.h | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > > index ca5bc0eacb95..f65ef6f783d2 100644
> > > --- a/arch/x86/include/asm/msr-index.h
> > > +++ b/arch/x86/include/asm/msr-index.h
> > > @@ -59,6 +59,9 @@
> > > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> > >
> > > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
> >
> > Please don't put comments into definitions.
>
> I'll remove the comment and change definitions of the MSR and the split lock
> detection bit as following:
>
> +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
> +#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
>
> Are these right changes?
I suspect it could be shortened to CORE_CAP as you (partly) did it
originally.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v8 05/15] x86/msr-index: Define MSR_IA32_CORE_CAPABILITY and split lock detection bit
From: Fenghua Yu @ 2019-04-25 19:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li, Christopherson Sean J, Kalle Valo,
Michael Chan, linux-kernel, x86, kvm, netdev, linux-wireless
In-Reply-To: <20190425054511.GA40105@gmail.com>
On Thu, Apr 25, 2019 at 07:45:11AM +0200, Ingo Molnar wrote:
>
> * Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> > A new MSR_IA32_CORE_CAPABILITY (0xcf) is defined. Each bit in the MSR
> > enumerates a model specific feature. Currently bit 5 enumerates split
> > lock detection. When bit 5 is 1, split lock detection is supported.
> > When the bit is 0, split lock detection is not supported.
> >
> > Please check the latest Intel 64 and IA-32 Architectures Software
> > Developer's Manual for more detailed information on the MSR and the
> > split lock detection bit.
> >
> > Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> > ---
> > arch/x86/include/asm/msr-index.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> > index ca5bc0eacb95..f65ef6f783d2 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -59,6 +59,9 @@
> > #define MSR_PLATFORM_INFO_CPUID_FAULT_BIT 31
> > #define MSR_PLATFORM_INFO_CPUID_FAULT BIT_ULL(MSR_PLATFORM_INFO_CPUID_FAULT_BIT)
> >
> > +#define MSR_IA32_CORE_CAPABILITY 0x000000cf
> > +#define CORE_CAP_SPLIT_LOCK_DETECT BIT(5) /* Detect split lock */
>
> Please don't put comments into definitions.
I'll remove the comment and change definitions of the MSR and the split lock
detection bit as following:
+#define MSR_IA32_CORE_CAPABILITY 0x000000cf
+#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT 5
+#define MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT BIT(MSR_IA32_CORE_CAPABILITY_SPLIT_LOCK_DETECT_BIT)
Are these right changes?
Thanks.
-Fenghua
^ permalink raw reply
* Re: [PATCH v2 25/79] docs: convert docs to ReST and rename to *.rst
From: Mark Brown @ 2019-04-25 18:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Bjorn Helgaas,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Johannes Berg, David S. Miller, linux-pm, linux-pci,
linux-arm-kernel, intel-gfx, dri-devel, linux-wireless, netdev
In-Reply-To: <7adf9035ae06ecc6c7e46b51cb677f0a8f61d19a.1555938376.git.mchehab+samsung@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Mon, Apr 22, 2019 at 10:27:14AM -0300, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
This is massively CCed covering a large range of subsystems and is patch
25 of a 79 patch series so I've no context for what's going on here or
why...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v8 03/15] wlcore: simplify/fix/optimize reg_ch_conf_pending operations
From: Kalle Valo @ 2019-04-25 17:12 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H Peter Anvin,
Paolo Bonzini, Dave Hansen, Ashok Raj, Peter Zijlstra,
Ravi V Shankar, Xiaoyao Li , Christopherson Sean J, Michael Chan,
linux-kernel, x86, kvm, netdev, linux-wireless, Fenghua Yu
In-Reply-To: <1556134382-58814-4-git-send-email-fenghua.yu@intel.com>
Fenghua Yu <fenghua.yu@intel.com> wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
>
> Bitmaps are defined on unsigned longs, so the usage of u32[2] in the
> wlcore driver is incorrect. As noted by Peter Zijlstra, casting arrays
> to a bitmap is incorrect for big-endian architectures.
>
> When looking at it I observed that:
>
> - operations on reg_ch_conf_pending is always under the wl_lock mutex,
> so set_bit is overkill
>
> - the only case where reg_ch_conf_pending is accessed a u32 at a time is
> unnecessary too.
>
> This patch cleans up everything in this area, and changes tmp_ch_bitmap
> to have the proper alignment.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Patch applied to wireless-drivers-next.git, thanks.
147b502bda33 wlcore: simplify/fix/optimize reg_ch_conf_pending operations
--
https://patchwork.kernel.org/patch/10915635/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: send mailbox interrupt twice for specific hardware device
From: Kalle Valo @ 2019-04-25 16:59 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel@broadcom.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, Chi-Hsien Lin, Wright Feng,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
In-Reply-To: <1556175939-174559-1-git-send-email-wright.feng@cypress.com>
Wright Feng <Wright.Feng@cypress.com> wrote:
> For PCIE wireless device with core revision less than 14, device may miss
> PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending
> mail box interrupt twice as a hardware workaround.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Failed to compile:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c: In function 'brcmf_pcie_send_mb_data':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:703:2: error: 'core' undeclared (first use in this function); did you mean 'cred'?
core = brcmf_chip_get_core(devinfo->ci, BCMA_CORE_PCIE2);
^~~~
cred
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c:703:2: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.o] Error 1
make[5]: *** [drivers/net/wireless/broadcom/brcm80211/brcmfmac] Error 2
make[4]: *** [drivers/net/wireless/broadcom/brcm80211] Error 2
make[3]: *** [drivers/net/wireless/broadcom] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10916093/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] rt2x00: add RT3883 support
From: Kalle Valo @ 2019-04-25 16:58 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Tomislav Požega, Daniel Golle, Felix Fietkau,
Mathias Kresin, Gabor Juhos, Stanislaw Gruszka
In-Reply-To: <1556092164-23823-1-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> From: Gabor Juhos <juhosg@openwrt.org>
>
> Patch add support for RT3883 chip. Code was taken direclty
> from openwrt project and merge into one patch.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
d0e61a0f7cca rt2x00: add RT3883 support
--
https://patchwork.kernel.org/patch/10914303/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs
From: Kalle Valo @ 2019-04-25 16:58 UTC (permalink / raw)
To: Hans de Goede
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Hans de Goede,
linux-wireless, brcm80211-dev-list.pdl, stable
In-Reply-To: <20190422204123.6123-1-hdegoede@redhat.com>
Hans de Goede <hdegoede@redhat.com> wrote:
> The ACEPC T8 and T11 mini PCs contain quite generic names in the sys_vendor
> and product_name DMI strings, without this patch brcmfmac will try to load:
> "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which
> is way too generic.
>
> The DMI strings on which we are matching are somewhat generic too, but
> "To be filled by O.E.M." is less common then "Default string" and the
> system-sku and bios-version strings are pretty unique. Beside the DMI
> strings we also check the wifi-module chip-id and revision. I'm confident
> that the combination of all this is unique.
>
> Both the T8 and T11 use the same wifi-module, this commit adds DMI
> quirks for both mini PCs pointing to brcmfmac43455-sdio.acepc-t8.txt .
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1690852
> Cc: stable@vger.kernel.org
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
b1a0ba8f772d brcmfmac: Add DMI nvram filename quirk for ACEPC T8 and T11 mini PCs
--
https://patchwork.kernel.org/patch/10911607/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: p54: drop device reference count if fails to enable device
From: Kalle Valo @ 2019-04-25 16:57 UTC (permalink / raw)
To: Pan Bian
Cc: Christian Lamparter, David S. Miller, linux-wireless, netdev,
linux-kernel, Pan Bian
In-Reply-To: <1555494083-130833-1-git-send-email-bianpan2016@163.com>
Pan Bian <bianpan2016@163.com> wrote:
> The function p54p_probe takes an extra reference count of the PCI
> device. However, the extra reference count is not dropped when it fails
> to enable the PCI device. This patch fixes the bug.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
8149069db818 p54: drop device reference count if fails to enable device
--
https://patchwork.kernel.org/patch/10905039/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 wireless-drivers-next] rtlwifi: rtl8723ae: Fix missing break in switch statement
From: Kalle Valo @ 2019-04-25 16:56 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Ping-Ke Shih, David S. Miller, Larry Finger, linux-wireless,
netdev, linux-kernel, Gustavo A. R. Silva, Kees Cook
In-Reply-To: <20190416151722.GA31598@embeddedor>
"Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote:
> Add missing break statement in order to prevent the code from falling
> through to case 0x1025, and erroneously setting rtlhal->oem_id to
> RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and
> none of the cases in switch (rtlefuse->eeprom_smid) match.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Patch applied to wireless-drivers-next.git, thanks.
84242b82d81c rtlwifi: rtl8723ae: Fix missing break in switch statement
--
https://patchwork.kernel.org/patch/10903325/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwifiex: fix spelling mistake "capabilties" -> "capabilities"
From: Kalle Valo @ 2019-04-25 16:55 UTC (permalink / raw)
To: Colin King
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S . Miller, linux-wireless, netdev, kernel-janitors,
linux-kernel
In-Reply-To: <20190415142649.18452-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There various spelling mistakes in function names and in message
> text. Fix these.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
3b989e58e88a mwifiex: fix spelling mistake "capabilties" -> "capabilities"
--
https://patchwork.kernel.org/patch/10900921/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
From: Kalle Valo @ 2019-04-25 16:54 UTC (permalink / raw)
To: Colin King
Cc: Stanislaw Gruszka, David S . Miller, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190415103703.11254-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Fix spelling mistakes in rx stats text. I missed these from an earlier
> round of fixing the same spelling mistake.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
b9574ce1d05e iwlegacy: fix spelling mistake "acumulative" -> "accumulative"
--
https://patchwork.kernel.org/patch/10900491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/1] mwifiex: add support for SD8987 chipset
From: Kalle Valo @ 2019-04-25 16:54 UTC (permalink / raw)
To: Tamás Szűcs
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
David S . Miller, open list:MARVELL MWIFIEX WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list, Cathy Luo, Zhiyuan Yang,
James Cao, Rakesh Parmar, Hemantkumar Suthar,
Tamás Szűcs
In-Reply-To: <20190414183641.7539-2-tszucs@protonmail.ch>
Tamás Szűcs wrote:
> This patch adds support for Marvell 88W8987 chipset with SDIO interface.
> Register offsets and supported feature flags are updated. The corresponding
> firmware image file shall be "mrvl/sd8987_uapsta.bin".
>
> Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch>
Patch applied to wireless-drivers-next.git, thanks.
938c7c80c78e mwifiex: add support for SD8987 chipset
--
https://patchwork.kernel.org/patch/10899927/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwl8k: Fix rate_idx underflow
From: Kalle Valo @ 2019-04-25 16:53 UTC (permalink / raw)
To: Petr Štetiar
Cc: linux-wireless, Lennert Buytenhek, Petr Štetiar, stable
In-Reply-To: <1555006410-6090-1-git-send-email-ynezz@true.cz>
Petr Štetiar wrote:
> It was reported on OpenWrt bug tracking system[1], that several users
> are affected by the endless reboot of their routers if they configure
> 5GHz interface with channel 44 or 48.
>
> The reboot loop is caused by the following excessive number of WARN_ON
> messages:
>
> WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516
> ieee80211_rx_napi+0x1fc/0xa54 [mac80211]
>
> as the messages are being correctly emitted by the following guard:
>
> case RX_ENC_LEGACY:
> if (WARN_ON(status->rate_idx >= sband->n_bitrates))
>
> as the rate_idx is in this case erroneously set to 251 (0xfb). This fix
> simply converts previously used magic number to proper constant and
> guards against substraction which is leading to the currently observed
> underflow.
>
> 1. https://bugs.openwrt.org/index.php?do=details&task_id=2218
>
> Fixes: 854783444bab ("mwl8k: properly set receive status rate index on 5 GHz receive")
> Cc: <stable@vger.kernel.org>
> Tested-by: Eubert Bao <bunnier@gmail.com>
> Reported-by: Eubert Bao <bunnier@gmail.com>
> Signed-off-by: Petr Štetiar <ynezz@true.cz>
Patch applied to wireless-drivers-next.git, thanks.
6b583201fa21 mwl8k: Fix rate_idx underflow
--
https://patchwork.kernel.org/patch/10896599/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] at76c50x-usb: Don't register led_trigger if usb_register_driver failed
From: Kalle Valo @ 2019-04-25 16:52 UTC (permalink / raw)
To: Yue Haibing; +Cc: linux-kernel, linux-wireless, davem, netdev, YueHaibing
In-Reply-To: <20190408034529.27500-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> Syzkaller report this:
>
> [ 1213.468581] BUG: unable to handle kernel paging request at fffffbfff83bf338
> [ 1213.469530] #PF error: [normal kernel read fault]
> [ 1213.469530] PGD 237fe4067 P4D 237fe4067 PUD 237e60067 PMD 1c868b067 PTE 0
> [ 1213.473514] Oops: 0000 [#1] SMP KASAN PTI
> [ 1213.473514] CPU: 0 PID: 6321 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8
> [ 1213.473514] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
> [ 1213.473514] RIP: 0010:strcmp+0x31/0xa0
> [ 1213.473514] Code: 00 00 00 00 fc ff df 55 53 48 83 ec 08 eb 0a 84 db 48 89 ef 74 5a 4c 89 e6 48 89 f8 48 89 fa 48 8d 6f 01 48 c1 e8 03 83 e2 07 <42> 0f b6 04 28 38 d0 7f 04 84 c0 75 50 48 89 f0 48 89 f2 0f b6 5d
> [ 1213.473514] RSP: 0018:ffff8881f2b7f950 EFLAGS: 00010246
> [ 1213.473514] RAX: 1ffffffff83bf338 RBX: ffff8881ea6f7240 RCX: ffffffff825350c6
> [ 1213.473514] RDX: 0000000000000000 RSI: ffffffffc1ee19c0 RDI: ffffffffc1df99c0
> [ 1213.473514] RBP: ffffffffc1df99c1 R08: 0000000000000001 R09: 0000000000000004
> [ 1213.473514] R10: 0000000000000000 R11: ffff8881de353f00 R12: ffff8881ee727900
> [ 1213.473514] R13: dffffc0000000000 R14: 0000000000000001 R15: ffffffffc1eeaaf0
> [ 1213.473514] FS: 00007fa66fa01700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000
> [ 1213.473514] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1213.473514] CR2: fffffbfff83bf338 CR3: 00000001ebb9e005 CR4: 00000000007606f0
> [ 1213.473514] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1213.473514] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 1213.473514] PKRU: 55555554
> [ 1213.473514] Call Trace:
> [ 1213.473514] led_trigger_register+0x112/0x3f0
> [ 1213.473514] led_trigger_register_simple+0x7a/0x110
> [ 1213.473514] ? 0xffffffffc1c10000
> [ 1213.473514] at76_mod_init+0x77/0x1000 [at76c50x_usb]
> [ 1213.473514] do_one_initcall+0xbc/0x47d
> [ 1213.473514] ? perf_trace_initcall_level+0x3a0/0x3a0
> [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
> [ 1213.473514] ? kasan_unpoison_shadow+0x30/0x40
> [ 1213.473514] do_init_module+0x1b5/0x547
> [ 1213.473514] load_module+0x6405/0x8c10
> [ 1213.473514] ? module_frob_arch_sections+0x20/0x20
> [ 1213.473514] ? kernel_read_file+0x1e6/0x5d0
> [ 1213.473514] ? find_held_lock+0x32/0x1c0
> [ 1213.473514] ? cap_capable+0x1ae/0x210
> [ 1213.473514] ? __do_sys_finit_module+0x162/0x190
> [ 1213.473514] __do_sys_finit_module+0x162/0x190
> [ 1213.473514] ? __ia32_sys_init_module+0xa0/0xa0
> [ 1213.473514] ? __mutex_unlock_slowpath+0xdc/0x690
> [ 1213.473514] ? wait_for_completion+0x370/0x370
> [ 1213.473514] ? vfs_write+0x204/0x4a0
> [ 1213.473514] ? do_syscall_64+0x18/0x450
> [ 1213.473514] do_syscall_64+0x9f/0x450
> [ 1213.473514] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 1213.473514] RIP: 0033:0x462e99
> [ 1213.473514] Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> [ 1213.473514] RSP: 002b:00007fa66fa00c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> [ 1213.473514] RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
> [ 1213.473514] RDX: 0000000000000000 RSI: 0000000020000300 RDI: 0000000000000003
> [ 1213.473514] RBP: 00007fa66fa00c70 R08: 0000000000000000 R09: 0000000000000000
> [ 1213.473514] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa66fa016bc
> [ 1213.473514] R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
>
> If usb_register failed, no need to call led_trigger_register_simple.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 1264b951463a ("at76c50x-usb: add driver")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
09ac2694b047 at76c50x-usb: Don't register led_trigger if usb_register_driver failed
--
https://patchwork.kernel.org/patch/10888765/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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