Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP
On Thu, 2018-07-05 at 12:06 -0500, Larry Finger wrote: > On 07/05/2018 02:36 AM, Pkshih wrote: > > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote: > >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger > >> wrote: > >>> We will have to agree to disagree. > >>> > >>> I have no idea what the vendors are doing that cause some motherboards to > >>> need a different aspm value. What I do know is that we have had to live > >>> with > >>> the idiocy of some vendors saving a few pennies by only including a single > >>> antenna, rather than two, and then making a problem by miscoding the EFUSE > >>> bit that indicates which connector is actually in use. As we have no means > >>> that I know about to detect which boxes have the problem, a module > >>> parameter > >>> was created, just as in this case. > >>> > >>> I agree that drivers should work "out of the box", but finite resources > >>> and > >>> lack of vendor cooperation make this a goal that may not be attainable. > >> > >> As you touched on, the ideal situation is that Realtek solve the > >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from > >> the commit log. The context is that the r8822 driver fails on several > >> platforms unless setting aspm=0 (the default is 1). > > > > It's hard to have all laptop or motherboards and all rtl8822be modules in > > my side, > > so what I can do is to analyze the issue when user encountered. > > > >> > >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba > >> https://bugzilla.kernel.org/show_bug.cgi?id=199651 > >> > >> > >> If we don't get a timely fix from Realtek though, I think there is a > >> key difference between the antenna selection headache and this one. In > >> the antenna case, there isn't a good value that you can set that will > >> work on all systems. If you change the default behaviour you will > >> solve the issue for some users while simultanously introducing the > >> problem on other systems that were previously fine. > >> > >> However in this case, it's highly likely that setting aspm=0 (off) by > >> default would work for everyone. It has the disadvantage of using a > >> bit more power, but especially with the indications that this issue > >> affects a significant number of systems, I think that having the > >> driver working out of the box everywhere is more important. The module > >> parameter can be left in place so that unaffected users that want to > >> save power can set aspm=1. > >> > > > > I think this issue may be due to L1 latency, so below patch would be > > helpful but not sure because I don't have the same laptop. > > Is there anyone can help to test? > > > > > > diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c > > b/drivers/staging/rtlwifi/rtl8822be/hw.c > > index 7947edb239a1..88ba5b2fea6a 100644 > > --- a/drivers/staging/rtlwifi/rtl8822be/hw.c > > +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c > > @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct > > ieee80211_hw *hw) > > return; > > > > pci_read_config_byte(rtlpci->pdev, 0x70f, ); > > - pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7)); > > + pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3); > > This patch loses the BIT(7). Did you really mean to do that? > > I now agree that this is a bug. A similar problem had been found in a few > boxes > with RTL8723BE or RTL8821AE cards, but that it might apply here completely > slipped through the ever larger cracks in my mind. > Yes, I remove BIT(7) intentionally, because this is defined as reserved bit in rtl8822be. For the older chips, I need to check with my colleagues. Regards, PK ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
> -Original Message- > From: Thomas Gleixner > Sent: Thursday, July 5, 2018 3:46 PM > To: Ingo Molnar > Cc: KY Srinivasan ; x...@kernel.org; > gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; h...@zytor.com; Stephen Hemminger > ; Michael Kelley (EOSG) > ; vkuzn...@redhat.com > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI > enlightenment. > > On Fri, 6 Jul 2018, Ingo Molnar wrote: > > * KY Srinivasan wrote: > > > I am confused. The label ipi_mask_done was introduced in this patch > > > (the patch under question fixes a circular dependency in this patch): > > > > > > commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a > > > Author: K. Y. Srinivasan > > > Date: Wed May 16 14:53:31 2018 -0700 > > > > > > X86/Hyper-V: Enable IPI enlightenments > > > > > > Hyper-V supports hypercalls to implement IPI; use them. > > > > > > Signed-off-by: K. Y. Srinivasan > > > Signed-off-by: Thomas Gleixner > > > Reviewed-by: Michael Kelley > > > > > > This patch was committed by Thomas some weeks ago and is in linux- > next. > > > This patch is also in 4.18-rc3. > > > > And then that name was changed to a different label in: > > > > 4bd06060762b: x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall > when possible > > > > So maybe you were testing on an older kernel. Could you try the latest - > tip? > > The problem is that the wreckage is in Linus tree and needs to be fixed > there, i.e. via x86/urgent. > > Now we have the new bits queued in x86/hyperv already which collide. So > we > need to merge x86/urgent into x86/hyperv after applying the fix and mop up > the merge wreckage in x86/hyperv. > > I'll have a look tomorrow morning unless you beat me to it. I can rebase this patch against the latest tip and resend (tomorrow). K. Y > > Thanks, > > tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: mt7621-pinctrl: Replace unsigned with unsigned int
Replaces instances of "unsigned" with "unsigned int" in pinctrl-mt7621.c
Signed-off-by: Peter Vernia
---
drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 27 +
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
index 0c3e498..201df08 100644
--- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
@@ -54,7 +54,7 @@ static int rt2880_get_group_count(struct pinctrl_dev
*pctrldev)
}
static const char *rt2880_get_group_name(struct pinctrl_dev *pctrldev,
-unsigned group)
+unsigned int group)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -65,9 +65,9 @@ static const char *rt2880_get_group_name(struct pinctrl_dev
*pctrldev,
}
static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
-unsigned group,
-const unsigned **pins,
-unsigned *num_pins)
+unsigned int group,
+const unsigned int **pins,
+unsigned int *num_pins)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -81,7 +81,8 @@ static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
}
static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev *pctrldev,
- struct pinctrl_map *map, unsigned num_maps)
+ struct pinctrl_map *map,
+ unsigned int num_maps)
{
int i;
@@ -94,7 +95,7 @@ static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev
*pctrldev,
static void rt2880_pinctrl_pin_dbg_show(struct pinctrl_dev *pctrldev,
struct seq_file *s,
- unsigned offset)
+ unsigned int offset)
{
seq_printf(s, "ralink pio");
}
@@ -127,7 +128,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
static int rt2880_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrldev,
struct device_node *np_config,
struct pinctrl_map **map,
- unsigned *num_maps)
+ unsigned int *num_maps)
{
int max_maps = 0;
struct pinctrl_map *tmp;
@@ -173,7 +174,7 @@ static int rt2880_pmx_func_count(struct pinctrl_dev
*pctrldev)
}
static const char *rt2880_pmx_func_name(struct pinctrl_dev *pctrldev,
-unsigned func)
+unsigned int func)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -181,9 +182,9 @@ static const char *rt2880_pmx_func_name(struct pinctrl_dev
*pctrldev,
}
static int rt2880_pmx_group_get_groups(struct pinctrl_dev *pctrldev,
- unsigned func,
+ unsigned int func,
const char * const **groups,
- unsigned * const num_groups)
+ unsigned int * const num_groups)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -198,8 +199,8 @@ static int rt2880_pmx_group_get_groups(struct pinctrl_dev
*pctrldev,
}
static int rt2880_pmx_group_enable(struct pinctrl_dev *pctrldev,
- unsigned func,
- unsigned group)
+ unsigned int func,
+ unsigned int group)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
u32 mode = 0;
@@ -243,7 +244,7 @@ static int rt2880_pmx_group_enable(struct pinctrl_dev
*pctrldev,
static int rt2880_pmx_group_gpio_request_enable(struct pinctrl_dev *pctrldev,
struct pinctrl_gpio_range *range,
- unsigned pin)
+ unsigned int pin)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/2] dt-bindings: document gpio-mt7621 bindings
On Thu, Jul 05, 2018 at 03:43:11PM +0200, Sergio Paracuellos wrote: > Add a devicetree binding documentation for the mt7621 gpio. > > Signed-off-by: Sergio Paracuellos > Reviewed-by: NeilBrown > --- > .../bindings/gpio/mediatek,mt7621-gpio.txt | 35 > ++ > 1 file changed, 35 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
On Fri, 6 Jul 2018, Ingo Molnar wrote: > * KY Srinivasan wrote: > > I am confused. The label ipi_mask_done was introduced in this patch > > (the patch under question fixes a circular dependency in this patch): > > > > commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a > > Author: K. Y. Srinivasan > > Date: Wed May 16 14:53:31 2018 -0700 > > > > X86/Hyper-V: Enable IPI enlightenments > > > > Hyper-V supports hypercalls to implement IPI; use them. > > > > Signed-off-by: K. Y. Srinivasan > > Signed-off-by: Thomas Gleixner > > Reviewed-by: Michael Kelley > > > > This patch was committed by Thomas some weeks ago and is in linux-next. > > This patch is also in 4.18-rc3. > > And then that name was changed to a different label in: > > 4bd06060762b: x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall when > possible > > So maybe you were testing on an older kernel. Could you try the latest -tip? The problem is that the wreckage is in Linus tree and needs to be fixed there, i.e. via x86/urgent. Now we have the new bits queued in x86/hyperv already which collide. So we need to merge x86/urgent into x86/hyperv after applying the fix and mop up the merge wreckage in x86/hyperv. I'll have a look tomorrow morning unless you beat me to it. Thanks, tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
* KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Ingo Molnar On Behalf Of Ingo Molnar
> > Sent: Thursday, July 5, 2018 8:38 AM
> > To: KY Srinivasan
> > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > h...@zytor.com; Stephen Hemminger ; Michael
> > Kelley (EOSG) ; vkuzn...@redhat.com
> > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> > enlightenment.
> >
> >
> > * KY Srinivasan wrote:
> >
> > >
> > >
> > > > -Original Message-
> > > > From: Ingo Molnar On Behalf Of Ingo
> > Molnar
> > > > Sent: Wednesday, July 4, 2018 9:11 AM
> > > > To: KY Srinivasan
> > > > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > > > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > > > h...@zytor.com; Stephen Hemminger ;
> > Michael
> > > > Kelley (EOSG) ;
> > vkuzn...@redhat.com
> > > > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in
> > > > IPI
> > > > enlightenment.
> > > >
> > > >
> > > > * k...@linuxonhyperv.com wrote:
> > > >
> > > > > From: "K. Y. Srinivasan"
> > > > >
> > > > > The IPI hypercalls depend on being able to map the Linux notion of CPU
> > ID
> > > > > to the hypervisor's notion of the CPU ID. The array hv_vp_index[]
> > provides
> > > > > this mapping. Code for populating this array depends on the IPI
> > > > functionality.
> > > > > Break this circular dependency.
> > > > >
> > > > > Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> > > > >
> > > > > Signed-off-by: K. Y. Srinivasan
> > > > > Tested-by: Michael Kelley
> > > > > ---
> > > > > arch/x86/hyperv/hv_apic.c | 5 +
> > > > > arch/x86/hyperv/hv_init.c | 5 -
> > > > > arch/x86/include/asm/mshyperv.h | 2 ++
> > > > > 3 files changed, 11 insertions(+), 1 deletion(-)
> > > >
> > > > Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:
> > > >
> > > > arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
> > > > arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but
> > not
> > > > defined
> > > > scripts/Makefile.build:317: recipe for target
> > > > 'arch/x86/hyperv/hv_apic.o'
> > > > failed
> > > > make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1
> > >
> > > Sorry Ingo. I had a clean build on the linux-next tree (tag:
> > > next-20180702)
> > that
> > > I used to base this patch. What was the tree you applied the patch to?
> >
> > If you look at the error message, it won't build against *any* tree, because
> > there's no 'ipi_mask_done' label either in the kernel source, or introduced
> > by the patch.
> >
> > So whatever tree you used it on, if you build arch/x86/hyperv/hv_apic.o it
> > should
> > be broken.
>
> Ingo,
>
> I am confused. The label ipi_mask_done was introduced in this patch
> (the patch under question fixes a circular dependency in this patch):
>
> commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a
> Author: K. Y. Srinivasan
> Date: Wed May 16 14:53:31 2018 -0700
>
> X86/Hyper-V: Enable IPI enlightenments
>
> Hyper-V supports hypercalls to implement IPI; use them.
>
> Signed-off-by: K. Y. Srinivasan
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Michael Kelley
>
> This patch was committed by Thomas some weeks ago and is in linux-next.
> This patch is also in 4.18-rc3.
And then that name was changed to a different label in:
4bd06060762b: x86/hyper-v: Use cheaper HVCALL_SEND_IPI hypercall when possible
So maybe you were testing on an older kernel. Could you try the latest -tip?
Thanks,
Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
> -Original Message-
> From: Ingo Molnar On Behalf Of Ingo Molnar
> Sent: Thursday, July 5, 2018 8:38 AM
> To: KY Srinivasan
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> h...@zytor.com; Stephen Hemminger ; Michael
> Kelley (EOSG) ; vkuzn...@redhat.com
> Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> enlightenment.
>
>
> * KY Srinivasan wrote:
>
> >
> >
> > > -Original Message-
> > > From: Ingo Molnar On Behalf Of Ingo
> Molnar
> > > Sent: Wednesday, July 4, 2018 9:11 AM
> > > To: KY Srinivasan
> > > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > > h...@zytor.com; Stephen Hemminger ;
> Michael
> > > Kelley (EOSG) ;
> vkuzn...@redhat.com
> > > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> > > enlightenment.
> > >
> > >
> > > * k...@linuxonhyperv.com wrote:
> > >
> > > > From: "K. Y. Srinivasan"
> > > >
> > > > The IPI hypercalls depend on being able to map the Linux notion of CPU
> ID
> > > > to the hypervisor's notion of the CPU ID. The array hv_vp_index[]
> provides
> > > > this mapping. Code for populating this array depends on the IPI
> > > functionality.
> > > > Break this circular dependency.
> > > >
> > > > Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> > > >
> > > > Signed-off-by: K. Y. Srinivasan
> > > > Tested-by: Michael Kelley
> > > > ---
> > > > arch/x86/hyperv/hv_apic.c | 5 +
> > > > arch/x86/hyperv/hv_init.c | 5 -
> > > > arch/x86/include/asm/mshyperv.h | 2 ++
> > > > 3 files changed, 11 insertions(+), 1 deletion(-)
> > >
> > > Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:
> > >
> > > arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
> > > arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but
> not
> > > defined
> > > scripts/Makefile.build:317: recipe for target 'arch/x86/hyperv/hv_apic.o'
> > > failed
> > > make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1
> >
> > Sorry Ingo. I had a clean build on the linux-next tree (tag: next-20180702)
> that
> > I used to base this patch. What was the tree you applied the patch to?
>
> If you look at the error message, it won't build against *any* tree, because
> there's no 'ipi_mask_done' label either in the kernel source, or introduced
> by the patch.
>
> So whatever tree you used it on, if you build arch/x86/hyperv/hv_apic.o it
> should
> be broken.
Ingo,
I am confused. The label ipi_mask_done was introduced in this patch
(the patch under question fixes a circular dependency in this patch):
commit 68bb7bfb7985df2bd15c2dc975cb68b7a901488a
Author: K. Y. Srinivasan
Date: Wed May 16 14:53:31 2018 -0700
X86/Hyper-V: Enable IPI enlightenments
Hyper-V supports hypercalls to implement IPI; use them.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Thomas Gleixner
Reviewed-by: Michael Kelley
This patch was committed by Thomas some weeks ago and is in linux-next.
This patch is also in 4.18-rc3.
Regards,
K. Y
>
> Thanks,
>
> Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging:fsl-mc: Move DPIO from staging to drivers/soc/fsl
Move the NXP DPIO (Datapath I/O Driver) out of the
drivers/staging directory and into the drivers/soc/fsl directory.
The DPIO driver enables access to Queue and Buffer Manager (QBMAN)
hardware on NXP DPAA2 devices. This is a prerequisite to moving the
DPAA2 Ethernet driver out of staging.
Signed-off-by: Roy Pledge
---
MAINTAINERS| 2 +-
drivers/crypto/caam/sg_sw_qm2.h| 2 +-
drivers/crypto/caam/sg_sw_sec4.h | 2 +-
drivers/soc/fsl/Kconfig| 10 ++
drivers/soc/fsl/Makefile | 1 +
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h| 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c | 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c| 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c| 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h| 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c| 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h| 2 +-
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h | 4 ++--
drivers/staging/fsl-mc/bus/Kconfig | 9 -
drivers/staging/fsl-mc/bus/Makefile| 2 --
{drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h | 0
.../staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h | 0
{drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h | 0
20 files changed, 20 insertions(+), 20 deletions(-)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h (99%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h (100%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h
(100%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index f771ec1..5b41d0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4442,7 +4442,7 @@ DPAA2 DATAPATH I/O (DPIO) DRIVER
M: Roy Pledge
L: linux-ker...@vger.kernel.org
S: Maintained
-F: drivers/staging/fsl-mc/bus/dpio
+F: drivers/soc/fsl/dpio
DPAA2 ETHERNET DRIVER
M: Ioana Radulescu
diff --git a/drivers/crypto/caam/sg_sw_qm2.h b/drivers/crypto/caam/sg_sw_qm2.h
index 31b4407..b5b4c12 100644
--- a/drivers/crypto/caam/sg_sw_qm2.h
+++ b/drivers/crypto/caam/sg_sw_qm2.h
@@ -35,7 +35,7 @@
#ifndef _SG_SW_QM2_H_
#define _SG_SW_QM2_H_
-#include "../../../drivers/staging/fsl-mc/include/dpaa2-fd.h"
+#include
static inline void dma_to_qm_sg_one(struct dpaa2_sg_entry *qm_sg_ptr,
dma_addr_t dma, u32 len, u16 offset)
diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index e586ffa..dbfa9fc 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -12,7 +12,7 @@
#include "ctrl.h"
#include "regs.h"
#include "sg_sw_qm2.h"
-#include "../../../drivers/staging/fsl-mc/include/dpaa2-fd.h"
+#include
struct sec4_sg_entry {
u64 ptr;
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 7a9fb9b..c17bf38 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -16,3 +16,13 @@ config FSL_GUTS
Initially only reading SVR and registering soc device are supported.
Other guts accesses, such as reading RCW, should eventually be moved
into this driver as well.
+
+config FSL_MC_DPIO
+tristate "QorIQ DPAA2 DPIO driver"
+depends on FSL_MC_BUS
+help
+ Driver for the DPAA2 DPIO object. A DPIO provides queue and
+ buffer management facilities for software to interact with
+ other DPAA2 objects. This driver does not expose the DPIO
+ objects individually, but groups them under a service layer
+ API.
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 44b3beb..803ef1b 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_FSL_DPAA) += qbman/
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM)
[PATCH 2/2] drivers/staging: Remove fsl-mc driver from staging
Remove the staging/drivers/fsl-mc directory from the staging area now that all the components have been moved to the main kernel areas. Signed-off-by: Roy Pledge --- drivers/staging/Kconfig | 2 -- drivers/staging/Makefile| 1 - drivers/staging/fsl-mc/Kconfig | 2 -- drivers/staging/fsl-mc/Makefile | 3 --- drivers/staging/fsl-mc/bus/Kconfig | 7 --- drivers/staging/fsl-mc/bus/Makefile | 7 --- 6 files changed, 22 deletions(-) delete mode 100644 drivers/staging/fsl-mc/Kconfig delete mode 100644 drivers/staging/fsl-mc/Makefile delete mode 100644 drivers/staging/fsl-mc/bus/Kconfig delete mode 100644 drivers/staging/fsl-mc/bus/Makefile diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index 9339af2..344fcf1 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -90,8 +90,6 @@ source "drivers/staging/clocking-wizard/Kconfig" source "drivers/staging/fbtft/Kconfig" -source "drivers/staging/fsl-mc/Kconfig" - source "drivers/staging/fsl-dpaa2/Kconfig" source "drivers/staging/wilc1000/Kconfig" diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index aa40b1f..2a84679 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -35,7 +35,6 @@ obj-$(CONFIG_GS_FPGABOOT) += gs_fpgaboot/ obj-$(CONFIG_UNISYSSPAR) += unisys/ obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/ obj-$(CONFIG_FB_TFT) += fbtft/ -obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/ obj-$(CONFIG_FSL_DPAA2)+= fsl-dpaa2/ obj-$(CONFIG_WILC1000) += wilc1000/ obj-$(CONFIG_MOST) += most/ diff --git a/drivers/staging/fsl-mc/Kconfig b/drivers/staging/fsl-mc/Kconfig deleted file mode 100644 index 3002229..000 --- a/drivers/staging/fsl-mc/Kconfig +++ /dev/null @@ -1,2 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -source "drivers/staging/fsl-mc/bus/Kconfig" diff --git a/drivers/staging/fsl-mc/Makefile b/drivers/staging/fsl-mc/Makefile deleted file mode 100644 index 1468388..000 --- a/drivers/staging/fsl-mc/Makefile +++ /dev/null @@ -1,3 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -# Freescale Management Complex (MC) bus drivers -obj-$(CONFIG_FSL_MC_BUS) += bus/ diff --git a/drivers/staging/fsl-mc/bus/Kconfig b/drivers/staging/fsl-mc/bus/Kconfig deleted file mode 100644 index 90f234d..000 --- a/drivers/staging/fsl-mc/bus/Kconfig +++ /dev/null @@ -1,7 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -# -# DPAA2 fsl-mc bus -# -# Copyright (C) 2014-2016 Freescale Semiconductor, Inc. -# - diff --git a/drivers/staging/fsl-mc/bus/Makefile b/drivers/staging/fsl-mc/bus/Makefile deleted file mode 100644 index 2141e4b..000 --- a/drivers/staging/fsl-mc/bus/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -# -# Freescale Management Complex (MC) bus drivers -# -# Copyright (C) 2014 Freescale Semiconductor, Inc. -# - -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/2] staging/fsl-mc/bus: Move DPIO from staging to drivers/soc/fsl
Move the NXP DPIO (Datapath I/O driver) from the staging/fsl-mc/bus/dpio
directory to the drivers/soc/fsl directory.
The DPIO driver enables access to the Queue and Buffer Managemer (QBMAN)
hardware of NXP DPAA2 devices. This is a prerequiste for moving the DPAA2
Ethernet device driver from the staging directory.
Roy Pledge (2):
staging:fsl-mc: Move DPIO from staging to drivers/soc/fsl
drivers/staging: Remove fsl-mc driver from staging
MAINTAINERS | 2 +-
drivers/crypto/caam/sg_sw_qm2.h | 2 +-
drivers/crypto/caam/sg_sw_sec4.h | 2 +-
drivers/soc/fsl/Kconfig | 10 ++
drivers/soc/fsl/Makefile | 1 +
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile| 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h | 0
.../{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c | 2 +-
.../{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt | 0
.../{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c | 2 +-
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c | 0
drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h | 0
.../{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c | 2 +-
.../{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h | 2 +-
drivers/staging/Kconfig | 2 --
drivers/staging/Makefile | 1 -
drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h | 4 ++--
drivers/staging/fsl-mc/Kconfig | 2 --
drivers/staging/fsl-mc/Makefile | 3 ---
drivers/staging/fsl-mc/bus/Kconfig | 16
drivers/staging/fsl-mc/bus/Makefile | 9 -
.../fsl-mc/include => include/soc/fsl}/dpaa2-fd.h| 0
.../fsl-mc/include => include/soc/fsl}/dpaa2-global.h| 0
.../fsl-mc/include => include/soc/fsl}/dpaa2-io.h| 0
24 files changed, 20 insertions(+), 42 deletions(-)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/Makefile (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-cmd.h (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-driver.txt (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio-service.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.c (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/dpio.h (100%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.c (99%)
rename drivers/{staging/fsl-mc/bus => soc/fsl}/dpio/qbman-portal.h (99%)
delete mode 100644 drivers/staging/fsl-mc/Kconfig
delete mode 100644 drivers/staging/fsl-mc/Makefile
delete mode 100644 drivers/staging/fsl-mc/bus/Kconfig
delete mode 100644 drivers/staging/fsl-mc/bus/Makefile
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-fd.h (100%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-global.h
(100%)
rename {drivers/staging/fsl-mc/include => include/soc/fsl}/dpaa2-io.h (100%)
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP
On 07/05/2018 02:36 AM, Pkshih wrote: On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote: On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger wrote: We will have to agree to disagree. I have no idea what the vendors are doing that cause some motherboards to need a different aspm value. What I do know is that we have had to live with the idiocy of some vendors saving a few pennies by only including a single antenna, rather than two, and then making a problem by miscoding the EFUSE bit that indicates which connector is actually in use. As we have no means that I know about to detect which boxes have the problem, a module parameter was created, just as in this case. I agree that drivers should work "out of the box", but finite resources and lack of vendor cooperation make this a goal that may not be attainable. As you touched on, the ideal situation is that Realtek solve the issue. Ping-Ke Shih is on CC and I am adding a few more contacts from the commit log. The context is that the r8822 driver fails on several platforms unless setting aspm=0 (the default is 1). It's hard to have all laptop or motherboards and all rtl8822be modules in my side, so what I can do is to analyze the issue when user encountered. https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba https://bugzilla.kernel.org/show_bug.cgi?id=199651 If we don't get a timely fix from Realtek though, I think there is a key difference between the antenna selection headache and this one. In the antenna case, there isn't a good value that you can set that will work on all systems. If you change the default behaviour you will solve the issue for some users while simultanously introducing the problem on other systems that were previously fine. However in this case, it's highly likely that setting aspm=0 (off) by default would work for everyone. It has the disadvantage of using a bit more power, but especially with the indications that this issue affects a significant number of systems, I think that having the driver working out of the box everywhere is more important. The module parameter can be left in place so that unaffected users that want to save power can set aspm=1. I think this issue may be due to L1 latency, so below patch would be helpful but not sure because I don't have the same laptop. Is there anyone can help to test? diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c b/drivers/staging/rtlwifi/rtl8822be/hw.c index 7947edb239a1..88ba5b2fea6a 100644 --- a/drivers/staging/rtlwifi/rtl8822be/hw.c +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct ieee80211_hw *hw) return; pci_read_config_byte(rtlpci->pdev, 0x70f, ); - pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7)); + pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3); This patch loses the BIT(7). Did you really mean to do that? I now agree that this is a bug. A similar problem had been found in a few boxes with RTL8723BE or RTL8821AE cards, but that it might apply here completely slipped through the ever larger cracks in my mind. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
* KY Srinivasan wrote:
>
>
> > -Original Message-
> > From: Ingo Molnar On Behalf Of Ingo Molnar
> > Sent: Wednesday, July 4, 2018 9:11 AM
> > To: KY Srinivasan
> > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> > a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> > h...@zytor.com; Stephen Hemminger ; Michael
> > Kelley (EOSG) ; vkuzn...@redhat.com
> > Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> > enlightenment.
> >
> >
> > * k...@linuxonhyperv.com wrote:
> >
> > > From: "K. Y. Srinivasan"
> > >
> > > The IPI hypercalls depend on being able to map the Linux notion of CPU ID
> > > to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides
> > > this mapping. Code for populating this array depends on the IPI
> > functionality.
> > > Break this circular dependency.
> > >
> > > Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> > >
> > > Signed-off-by: K. Y. Srinivasan
> > > Tested-by: Michael Kelley
> > > ---
> > > arch/x86/hyperv/hv_apic.c | 5 +
> > > arch/x86/hyperv/hv_init.c | 5 -
> > > arch/x86/include/asm/mshyperv.h | 2 ++
> > > 3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:
> >
> > arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
> > arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but not
> > defined
> > scripts/Makefile.build:317: recipe for target 'arch/x86/hyperv/hv_apic.o'
> > failed
> > make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1
>
> Sorry Ingo. I had a clean build on the linux-next tree (tag: next-20180702)
> that
> I used to base this patch. What was the tree you applied the patch to?
If you look at the error message, it won't build against *any* tree, because
there's no 'ipi_mask_done' label either in the kernel source, or introduced
by the patch.
So whatever tree you used it on, if you build arch/x86/hyperv/hv_apic.o it
should
be broken.
Thanks,
Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
> -Original Message-
> From: Ingo Molnar On Behalf Of Ingo Molnar
> Sent: Wednesday, July 4, 2018 9:11 AM
> To: KY Srinivasan
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; t...@linutronix.de;
> h...@zytor.com; Stephen Hemminger ; Michael
> Kelley (EOSG) ; vkuzn...@redhat.com
> Subject: Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI
> enlightenment.
>
>
> * k...@linuxonhyperv.com wrote:
>
> > From: "K. Y. Srinivasan"
> >
> > The IPI hypercalls depend on being able to map the Linux notion of CPU ID
> > to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides
> > this mapping. Code for populating this array depends on the IPI
> functionality.
> > Break this circular dependency.
> >
> > Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
> >
> > Signed-off-by: K. Y. Srinivasan
> > Tested-by: Michael Kelley
> > ---
> > arch/x86/hyperv/hv_apic.c | 5 +
> > arch/x86/hyperv/hv_init.c | 5 -
> > arch/x86/include/asm/mshyperv.h | 2 ++
> > 3 files changed, 11 insertions(+), 1 deletion(-)
>
> Ugh, this patch wasn't even build tested, on 64-bit allyes/allmodconfig:
>
> arch/x86/hyperv/hv_apic.c: In function ‘__send_ipi_mask’:
> arch/x86/hyperv/hv_apic.c:171:4: error: label ‘ipi_mask_done’ used but not
> defined
> scripts/Makefile.build:317: recipe for target 'arch/x86/hyperv/hv_apic.o'
> failed
> make[2]: *** [arch/x86/hyperv/hv_apic.o] Error 1
Sorry Ingo. I had a clean build on the linux-next tree (tag: next-20180702) that
I used to base this patch. What was the tree you applied the patch to?
Regards,
K. Y
>
> Thanks,
>
> Ingo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 1/2] gpio: mediatek: add driver for MT7621
Add driver support for gpio of MT7621 SoC.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
drivers/gpio/Kconfig | 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mt7621.c | 331 +
3 files changed, 340 insertions(+)
create mode 100644 drivers/gpio/gpio-mt7621.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 71c0ab4..836aa21 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -359,6 +359,14 @@ config GPIO_MPC8XXX
Say Y here if you're going to use hardware that connects to the
MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
+config GPIO_MT7621
+ bool "Mediatek MT7621 GPIO Support"
+ depends on SOC_MT7620 || SOC_MT7621 || COMPILE_TEST
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to support the Mediatek MT7621 SoC GPIO device
+
config GPIO_MVEBU
def_bool y
depends on PLAT_ORION || ARCH_MVEBU
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1324c8f..fc77989 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
+obj-$(CONFIG_GPIO_MT7621) += gpio-mt7621.o
obj-$(CONFIG_GPIO_MVEBU)+= gpio-mvebu.o
obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
new file mode 100644
index 000..d7256b5
--- /dev/null
+++ b/drivers/gpio/gpio-mt7621.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2009-2011 Gabor Juhos
+ * Copyright (C) 2013 John Crispin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_BANK_CNT 3
+#define MTK_BANK_WIDTH 32
+
+#define GPIO_BANK_WIDE 0x04
+#define GPIO_REG_CTRL 0x00
+#define GPIO_REG_POL 0x10
+#define GPIO_REG_DATA 0x20
+#define GPIO_REG_DSET 0x30
+#define GPIO_REG_DCLR 0x40
+#define GPIO_REG_REDGE 0x50
+#define GPIO_REG_FEDGE 0x60
+#define GPIO_REG_HLVL 0x70
+#define GPIO_REG_LLVL 0x80
+#define GPIO_REG_STAT 0x90
+#define GPIO_REG_EDGE 0xA0
+
+struct mtk_gc {
+ struct gpio_chip chip;
+ spinlock_t lock;
+ int bank;
+ u32 rising;
+ u32 falling;
+ u32 hlevel;
+ u32 llevel;
+};
+
+/**
+ * struct mtk_data - state container for
+ * data of the platform driver. It is 3
+ * separate gpio-chip each one with its
+ * own irq_chip.
+ * @dev: device instance
+ * @gpio_membase: memory base address
+ * @gpio_irq: irq number from the device tree
+ * @gc_map: array of the gpio chips
+ */
+struct mtk_data {
+ struct device *dev;
+ void __iomem *gpio_membase;
+ int gpio_irq;
+ struct mtk_gc gc_map[MTK_BANK_CNT];
+};
+
+static inline struct mtk_gc *
+to_mediatek_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct mtk_gc, chip);
+}
+
+static inline void
+mtk_gpio_w32(struct mtk_gc *rg, u32 offset, u32 val)
+{
+ struct gpio_chip *gc = >chip;
+ struct mtk_data *gpio_data = gpiochip_get_data(gc);
+
+ offset = (rg->bank * GPIO_BANK_WIDE) + offset;
+ gc->write_reg(gpio_data->gpio_membase + offset, val);
+}
+
+static inline u32
+mtk_gpio_r32(struct mtk_gc *rg, u32 offset)
+{
+ struct gpio_chip *gc = >chip;
+ struct mtk_data *gpio_data = gpiochip_get_data(gc);
+
+ offset = (rg->bank * GPIO_BANK_WIDE) + offset;
+ return gc->read_reg(gpio_data->gpio_membase + offset);
+}
+
+static irqreturn_t
+mediatek_gpio_irq_handler(int irq, void *data)
+{
+ struct gpio_chip *gc = data;
+ struct mtk_gc *rg = to_mediatek_gpio(gc);
+ irqreturn_t ret = IRQ_NONE;
+ unsigned long pending;
+ int bit;
+
+ pending = mtk_gpio_r32(rg, GPIO_REG_STAT);
+
+ for_each_set_bit(bit, , MTK_BANK_WIDTH) {
+ u32 map = irq_find_mapping(gc->irq.domain, bit);
+
+ generic_handle_irq(map);
+ mtk_gpio_w32(rg, GPIO_REG_STAT, BIT(bit));
+ ret |= IRQ_HANDLED;
+ }
+
+ return ret;
+}
+
+static void
+mediatek_gpio_irq_unmask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct mtk_gc *rg = to_mediatek_gpio(gc);
+ int pin = d->hwirq;
+ unsigned long flags;
+ u32 rise, fall, high, low;
+
+ spin_lock_irqsave(>lock, flags);
+ rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
+ fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
+ high = mtk_gpio_r32(rg, GPIO_REG_HLVL);
+ low = mtk_gpio_r32(rg, GPIO_REG_LLVL);
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (BIT(pin) & rg->rising));
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (BIT(pin) & rg->falling));
+ mtk_gpio_w32(rg,
[PATCH v4 0/2] gpio: mediatek: driver for gpio chip in MT7621 SoC
This patch series add support for gpio driver in mediatek MT7621 SoC. This driver has been in staging for a while and after some cleanups cycles we consider to give it a new try to get mainlined. Previous comments from Linus Walleij are here: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/121742.html Comments from Rob Herring are here: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/121974.html Changes in v4: - Fix gpio banks naming issues - Use custom xlate to be able to use only one node in DT. - Add Reviewed-by: NeilBrown to the patches. Changes in v3: - Fix added Makefile entry which was wrong. Changes in v2 are the ones pointed out in previous mails: - use bgpio_init - avoid custom irq_domain using IRQF_SHARED and gpiochip_set_chained_irqchip from GPIOLIB_IRQCHIP - use only one node in the device tree making it simple - Implement high and low level irqs - avoid include gpio.h - use builtin_platform_driver - add COMPILE_TEST - cleanups after this changes Hope this helps and thanks in advance. Best regards, Sergio Paracuellos Sergio Paracuellos (2): gpio: mediatek: add driver for MT7621 dt-bindings: document gpio-mt7621 bindings .../bindings/gpio/mediatek,mt7621-gpio.txt | 35 +++ drivers/gpio/Kconfig | 8 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-mt7621.c | 331 + 4 files changed, 375 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt create mode 100644 drivers/gpio/gpio-mt7621.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 2/2] dt-bindings: document gpio-mt7621 bindings
Add a devicetree binding documentation for the mt7621 gpio.
Signed-off-by: Sergio Paracuellos
Reviewed-by: NeilBrown
---
.../bindings/gpio/mediatek,mt7621-gpio.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
new file mode 100644
index 000..ba45558
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
@@ -0,0 +1,35 @@
+Mediatek MT7621 SoC GPIO controller bindings
+
+The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
+The registers of all the banks are interwoven inside one single IO range.
+We load one GPIO controller instance per bank. Also the GPIO controller can
receive
+interrupts on any of the GPIOs, either edge or level. It then interrupts the
CPU
+using GIC INT12.
+
+Required properties for the top level node:
+- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
+ second cell specifies GPIO flags, as defined in .
+ Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt. Should be 2. The first cell defines the interrupt number,
+ the second encodes the triger flags encoded as described in
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+- compatible:
+ - "mediatek,mt7621-gpio" for Mediatek controllers
+- reg : Physical base address and length of the controller's registers
+- interrupt-parent : phandle of the parent interrupt controller.
+- interrupts : Interrupt specifier for the controllers interrupt.
+- interrupt-controller : Mark the device node as an interrupt controller.
+- gpio-controller : Marks the device node as a GPIO controller.
+
+Example:
+ gpio@600 {
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ compatible = "mediatek,mt7621-gpio";
+ gpio-controller;
+ interrupt-controller;
+ reg = <0x600 0x100>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: mt7621-mmc: Fix printk() facility level
The patch fixes the following issue:
WARNING: printk() should include KERN_ facility level
Signed-off-by: Sergej Perschin
Signed-off-by: Marcel Budoj
---
drivers/staging/mt7621-mmc/dbg.c | 54
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/dbg.c b/drivers/staging/mt7621-mmc/dbg.c
index 6e4e223..6e518dc 100644
--- a/drivers/staging/mt7621-mmc/dbg.c
+++ b/drivers/staging/mt7621-mmc/dbg.c
@@ -91,11 +91,11 @@ u32 msdc_time_calc(u32 old_L32, u32 old_H32, u32 new_L32,
u32 new_H32)
ret = new_L32 - old_L32;
} else if (new_H32 == (old_H32 + 1)) {
if (new_L32 > old_L32)
- printk("msdc old_L<0x%x> new_L<0x%x>\n", old_L32,
new_L32);
+ pr_debug("msdc old_L<0x%x> new_L<0x%x>\n", old_L32,
new_L32);
ret = (0x - old_L32);
ret += new_L32;
} else {
- printk("msdc old_H<0x%x> new_H<0x%x>\n", old_H32, new_H32);
+ pr_debug("msdc old_H<0x%x> new_H<0x%x>\n", old_H32, new_H32);
}
return ret;
@@ -106,34 +106,34 @@ void msdc_sdio_profile(struct sdio_profile *result)
struct cmd_profile *cmd;
u32 i;
- printk("sdio === performance dump ===\n");
- printk("sdio === total execute tick<%d> time<%dms> Tx<%dB> Rx<%dB>\n",
- result->total_tc, result->total_tc / TICKS_ONE_MS,
- result->total_tx_bytes, result->total_rx_bytes);
+ pr_debug("sdio === performance dump ===\n");
+ pr_debug("sdio === total execute tick<%d> time<%dms> Tx<%dB> Rx<%dB>\n",
+result->total_tc, result->total_tc / TICKS_ONE_MS,
+result->total_tx_bytes, result->total_rx_bytes);
/* CMD52 Dump */
cmd = >cmd52_rx;
- printk("sdio === CMD52 Rx <%d>times tick<%d> Max<%d> Min<%d>
Aver<%d>\n", cmd->count, cmd->tot_tc,
- cmd->max_tc, cmd->min_tc, cmd->tot_tc / cmd->count);
+ pr_debug("sdio === CMD52 Rx <%d>times tick<%d> Max<%d> Min<%d>
Aver<%d>\n", cmd->count, cmd->tot_tc,
+cmd->max_tc, cmd->min_tc, cmd->tot_tc / cmd->count);
cmd = >cmd52_tx;
- printk("sdio === CMD52 Tx <%d>times tick<%d> Max<%d> Min<%d>
Aver<%d>\n", cmd->count, cmd->tot_tc,
- cmd->max_tc, cmd->min_tc, cmd->tot_tc / cmd->count);
+ pr_debug("sdio === CMD52 Tx <%d>times tick<%d> Max<%d> Min<%d>
Aver<%d>\n", cmd->count, cmd->tot_tc,
+cmd->max_tc, cmd->min_tc, cmd->tot_tc / cmd->count);
/* CMD53 Rx bytes + block mode */
for (i = 0; i < 512; i++) {
cmd = >cmd53_rx_byte[i];
if (cmd->count) {
-
printk("sdio<%6d><%3dB>_Rx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n", cmd->count, i,
cmd->tot_tc,
- cmd->max_tc, cmd->min_tc, cmd->tot_tc /
cmd->count,
- cmd->tot_bytes, (cmd->tot_bytes / 10) * 13 /
(cmd->tot_tc / 10));
+
pr_debug("sdio<%6d><%3dB>_Rx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n", cmd->count,
i, cmd->tot_tc,
+cmd->max_tc, cmd->min_tc, cmd->tot_tc /
cmd->count,
+cmd->tot_bytes, (cmd->tot_bytes / 10) * 13 /
(cmd->tot_tc / 10));
}
}
for (i = 0; i < 100; i++) {
cmd = >cmd53_rx_blk[i];
if (cmd->count) {
-
printk("sdio<%6d><%3d>B_Rx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n", cmd->count, i,
cmd->tot_tc,
- cmd->max_tc, cmd->min_tc, cmd->tot_tc /
cmd->count,
- cmd->tot_bytes, (cmd->tot_bytes / 10) * 13 /
(cmd->tot_tc / 10));
+
pr_debug("sdio<%6d><%3d>B_Rx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n", cmd->count,
i, cmd->tot_tc,
+cmd->max_tc, cmd->min_tc, cmd->tot_tc /
cmd->count,
+cmd->tot_bytes, (cmd->tot_bytes / 10) * 13 /
(cmd->tot_tc / 10));
}
}
@@ -141,21 +141,21 @@ void msdc_sdio_profile(struct sdio_profile *result)
for (i = 0; i < 512; i++) {
cmd = >cmd53_tx_byte[i];
if (cmd->count) {
-
printk("sdio<%6d><%3dB>_Tx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n", cmd->count, i,
cmd->tot_tc,
- cmd->max_tc, cmd->min_tc, cmd->tot_tc /
cmd->count,
- cmd->tot_bytes, (cmd->tot_bytes / 10) * 13 /
(cmd->tot_tc / 10));
+
pr_debug("sdio<%6d><%3dB>_Tx_<%9d><%9d><%6d><%6d>_<%9dB><%2dM>\n", cmd->count,
i, cmd->tot_tc,
+cmd->max_tc, cmd->min_tc, cmd->tot_tc /
cmd->count,
+cmd->tot_bytes, (cmd->tot_bytes / 10) * 13 /
(cmd->tot_tc / 10));
}
}
for (i = 0; i < 100; i++) {
Re: [PATCH 3/3] drivers/speakup: Fix style and coding warnings
On Tue, Jul 03, 2018 at 09:10:55AM +0100, Justin Skists wrote: > > @@ -787,7 +787,7 @@ static ssize_t message_store_helper(const char *buf, > > size_t count, > > continue; > > } > > > > - index = simple_strtoul(cp, , 10); > > + index = simple_ktrtoul(cp, , 10); > > Did you compile this? Try to avoid rhetorical questions. Just say "This doesn't compile. Be more careful." regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/3] drivers/speakup: Fix style and coding warnings
On Wed, Jul 04, 2018 at 10:46:05PM +0300, Tamir Suliman wrote: > > Interesting construct... Yeah I'm little bit rusty on my C /programming . > I understand proper coding style may be should end with else so I wasn't > sure .. however this resolved the warnings. :) The code you wrote was very wrong. It doesn't compile. You need to figure out what is wrong with your testing so that it doesn't happen again. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: wilc1000: fix static checker warning to unlock mutex in wilc_deinit()
Fix for static checker warning inconsistent returns of
'hif_deinit_lock'(more details [1]).
"drivers/staging/wilc1000/host_interface.c:3390 wilc_deinit()
warn: inconsistent returns 'hif_deinit_lock'."
Fixes: ff52a57a7a42 ("staging: wilc1000: move the allocation of cmd out
of wilc_enqueue_cmd()")
[1]. https://www.spinics.net/lists/linux-driver-devel/msg114216.html
Reported-by: Dan Carpenter
Signed-off-by: Ajay Singh
---
Change since v1:
- added 'Fixes' tag in commit description.
drivers/staging/wilc1000/host_interface.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 52c0c10..918d06e 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3370,15 +3370,15 @@ int wilc_deinit(struct wilc_vif *vif)
struct host_if_msg *msg;
msg = wilc_alloc_work(vif, handle_hif_exit_work, true);
- if (IS_ERR(msg))
- return PTR_ERR(msg);
-
- result = wilc_enqueue_work(msg);
- if (result)
- netdev_err(vif->ndev, "deinit : Error(%d)\n", result);
- else
- wait_for_completion(>work_comp);
- kfree(msg);
+ if (!IS_ERR(msg)) {
+ result = wilc_enqueue_work(msg);
+ if (result)
+ netdev_err(vif->ndev, "deinit : Error(%d)\n",
+ result);
+ else
+ wait_for_completion(>work_comp);
+ kfree(msg);
+ }
destroy_workqueue(hif_workqueue);
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: fix static checker warning to unlock mutex in wilc_deinit()
Hi Dan,
On Thu, 5 Jul 2018 11:41:26 +0300
Dan Carpenter wrote:
> On Thu, Jul 05, 2018 at 09:18:53AM +0530, Ajay Singh wrote:
> > Fix for static checker warning inconsistent returns of
> > 'hif_deinit_lock'(more details [1]).
> >
> > "drivers/staging/wilc1000/host_interface.c:3390 wilc_deinit()
> > warn: inconsistent returns 'hif_deinit_lock'."
> >
> > Introduced in "ff52a57a7a42: staging: wilc1000: move the allocation
> > of cmd out of wilc_enqueue_cmd()".
>
> Can you use the Fixes tag so it's machine parseable?
>
> Fixes: ff52a57a7a42 ("staging: wilc1000: move the allocation of cmd
> out of wilc_enqueue_cmd()")
Thanks for your suggestion.
Will include the 'Fixes' tag and submit patch v2 version.
>
> With the fixes tag, say someone pulls ff52a57a7a42 into their code,
> they will know to pull this patch as well. Also scientists will be
> able to measure the time between bug and fix and write a scholarly
> paper about it.
>
> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public
On 07/04/18 at 07:46pm, Andy Shevchenko wrote:
> On Wed, Jul 4, 2018 at 7:10 AM, Baoquan He wrote:
> > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> > so that it's shared.
>
> With couple of comments below,
Sure, will fix these and repost with your reviewed-by, thanks. Should be
after I reproduce and fix those issues reported by test robot.
>
> Reviewed-by: Andy Shevchenko
>
> P.S. In some commit message in this series you used 'likt' instead of 'like'.
>
> >
> > Signed-off-by: Baoquan He
> > ---
> > arch/microblaze/pci/pci-common.c | 37 -
> > arch/powerpc/kernel/pci-common.c | 35 ---
> > include/linux/ioport.h | 1 +
> > kernel/resource.c| 39
> > +++
> > 4 files changed, 40 insertions(+), 72 deletions(-)
> >
> > diff --git a/arch/microblaze/pci/pci-common.c
> > b/arch/microblaze/pci/pci-common.c
> > index f34346d56095..7899bafab064 100644
> > --- a/arch/microblaze/pci/pci-common.c
> > +++ b/arch/microblaze/pci/pci-common.c
> > @@ -619,43 +619,6 @@ int pcibios_add_device(struct pci_dev *dev)
> > EXPORT_SYMBOL(pcibios_add_device);
> >
> > /*
> > - * Reparent resource children of pr that conflict with res
> > - * under res, and make res replace those children.
> > - */
> > -static int __init reparent_resources(struct resource *parent,
> > -struct resource *res)
> > -{
> > - struct resource *p, **pp;
> > - struct resource **firstpp = NULL;
> > -
> > - for (pp = >child; (p = *pp) != NULL; pp = >sibling) {
> > - if (p->end < res->start)
> > - continue;
> > - if (res->end < p->start)
> > - break;
> > - if (p->start < res->start || p->end > res->end)
> > - return -1; /* not completely contained */
> > - if (firstpp == NULL)
> > - firstpp = pp;
> > - }
> > - if (firstpp == NULL)
> > - return -1; /* didn't find any conflicting entries? */
> > - res->parent = parent;
> > - res->child = *firstpp;
> > - res->sibling = *pp;
> > - *firstpp = res;
> > - *pp = NULL;
> > - for (p = res->child; p != NULL; p = p->sibling) {
> > - p->parent = res;
> > - pr_debug("PCI: Reparented %s [%llx..%llx] under %s\n",
> > -p->name,
> > -(unsigned long long)p->start,
> > -(unsigned long long)p->end, res->name);
> > - }
> > - return 0;
> > -}
> > -
> > -/*
> > * Handle resources of PCI devices. If the world were perfect, we could
> > * just allocate all the resource regions and do nothing more. It isn't.
> > * On the other hand, we cannot just re-allocate all devices, as it would
> > diff --git a/arch/powerpc/kernel/pci-common.c
> > b/arch/powerpc/kernel/pci-common.c
> > index fe9733aa..926035bb378d 100644
> > --- a/arch/powerpc/kernel/pci-common.c
> > +++ b/arch/powerpc/kernel/pci-common.c
> > @@ -1088,41 +1088,6 @@ resource_size_t pcibios_align_resource(void *data,
> > const struct resource *res,
> > EXPORT_SYMBOL(pcibios_align_resource);
> >
> > /*
> > - * Reparent resource children of pr that conflict with res
> > - * under res, and make res replace those children.
> > - */
> > -static int reparent_resources(struct resource *parent,
> > -struct resource *res)
> > -{
> > - struct resource *p, **pp;
> > - struct resource **firstpp = NULL;
> > -
> > - for (pp = >child; (p = *pp) != NULL; pp = >sibling) {
> > - if (p->end < res->start)
> > - continue;
> > - if (res->end < p->start)
> > - break;
> > - if (p->start < res->start || p->end > res->end)
> > - return -1; /* not completely contained */
> > - if (firstpp == NULL)
> > - firstpp = pp;
> > - }
> > - if (firstpp == NULL)
> > - return -1; /* didn't find any conflicting entries? */
> > - res->parent = parent;
> > - res->child = *firstpp;
> > - res->sibling = *pp;
> > - *firstpp = res;
> > - *pp = NULL;
> > - for (p = res->child; p != NULL; p = p->sibling) {
> > - p->parent = res;
> > - pr_debug("PCI: Reparented %s %pR under %s\n",
> > -p->name, p, res->name);
> > - }
> > - return 0;
> > -}
> > -
> > -/*
> > * Handle resources of PCI devices. If the world were perfect, we could
> > * just allocate all the resource regions and do nothing more. It isn't.
> > * On the other hand, we cannot just re-allocate all
Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP
2018-07-05 17:32 GMT+08:00 Dan Carpenter : > On Thu, Jul 05, 2018 at 05:26:28PM +0800, Jian-Hong Pan wrote: >> 2018-07-05 15:36 GMT+08:00 Pkshih : >> > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote: >> >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger >> >> wrote: >> >> > We will have to agree to disagree. >> >> > >> >> > I have no idea what the vendors are doing that cause some motherboards >> >> > to >> >> > need a different aspm value. What I do know is that we have had to live >> >> > with >> >> > the idiocy of some vendors saving a few pennies by only including a >> >> > single >> >> > antenna, rather than two, and then making a problem by miscoding the >> >> > EFUSE >> >> > bit that indicates which connector is actually in use. As we have no >> >> > means >> >> > that I know about to detect which boxes have the problem, a module >> >> > parameter >> >> > was created, just as in this case. >> >> > >> >> > I agree that drivers should work "out of the box", but finite resources >> >> > and >> >> > lack of vendor cooperation make this a goal that may not be attainable. >> >> >> >> As you touched on, the ideal situation is that Realtek solve the >> >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from >> >> the commit log. The context is that the r8822 driver fails on several >> >> platforms unless setting aspm=0 (the default is 1). >> > >> > It's hard to have all laptop or motherboards and all rtl8822be modules in >> > my side, >> > so what I can do is to analyze the issue when user encountered. >> > >> >> >> >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba >> >> https://bugzilla.kernel.org/show_bug.cgi?id=199651 >> >> >> >> >> >> If we don't get a timely fix from Realtek though, I think there is a >> >> key difference between the antenna selection headache and this one. In >> >> the antenna case, there isn't a good value that you can set that will >> >> work on all systems. If you change the default behaviour you will >> >> solve the issue for some users while simultanously introducing the >> >> problem on other systems that were previously fine. >> >> >> >> However in this case, it's highly likely that setting aspm=0 (off) by >> >> default would work for everyone. It has the disadvantage of using a >> >> bit more power, but especially with the indications that this issue >> >> affects a significant number of systems, I think that having the >> >> driver working out of the box everywhere is more important. The module >> >> parameter can be left in place so that unaffected users that want to >> >> save power can set aspm=1. >> >> >> > >> > I think this issue may be due to L1 latency, so below patch would be >> > helpful but not sure because I don't have the same laptop. >> > Is there anyone can help to test? >> >> I do not know why I cannot apply this patch directly. So, I apply >> each line manually. >> >> However, here is a good news. I tested this fix, and it works >> correctly on ASUS X530UN. System can scan and get the access points >> list. Finally, it also connects to the access point. >> Maybe, you can have a formal patch for this. >> > > That's good news. What does the "dmesg | grep r8822be" say now? dev@endless:~/linux-eos$ dmesg | grep r8822be [8.538404] r8822be: module is from the staging directory, the quality is unknown, you have been warned. [8.541706] r8822be :02:00.0: enabling device ( -> 0003) [8.571568] r8822be: Using firmware rtlwifi/rtl8822befw.bin [8.572370] r8822be: rtlwifi: wireless switch is on [8.573338] r8822be :02:00.0 wlp2s0: renamed from wlan0 [ 11.346560] Modules linked in: nouveau(+) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel mxm_wmi snd_hda_codec r8822be(C) x86_pkg_temp_thermal snd_hwdep snd_hda_core efivarfs i915 The warning message comes from nouveau. That is no matter. Here is the full dmesg https://gist.github.com/starnight/29b1ead5659868fcfb7f172e51a96535#file-gistfile1-txt Regards, Jian-Hong Pan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP
On Thu, Jul 05, 2018 at 05:26:28PM +0800, Jian-Hong Pan wrote: > 2018-07-05 15:36 GMT+08:00 Pkshih : > > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote: > >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger > >> wrote: > >> > We will have to agree to disagree. > >> > > >> > I have no idea what the vendors are doing that cause some motherboards to > >> > need a different aspm value. What I do know is that we have had to live > >> > with > >> > the idiocy of some vendors saving a few pennies by only including a > >> > single > >> > antenna, rather than two, and then making a problem by miscoding the > >> > EFUSE > >> > bit that indicates which connector is actually in use. As we have no > >> > means > >> > that I know about to detect which boxes have the problem, a module > >> > parameter > >> > was created, just as in this case. > >> > > >> > I agree that drivers should work "out of the box", but finite resources > >> > and > >> > lack of vendor cooperation make this a goal that may not be attainable. > >> > >> As you touched on, the ideal situation is that Realtek solve the > >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from > >> the commit log. The context is that the r8822 driver fails on several > >> platforms unless setting aspm=0 (the default is 1). > > > > It's hard to have all laptop or motherboards and all rtl8822be modules in > > my side, > > so what I can do is to analyze the issue when user encountered. > > > >> > >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba > >> https://bugzilla.kernel.org/show_bug.cgi?id=199651 > >> > >> > >> If we don't get a timely fix from Realtek though, I think there is a > >> key difference between the antenna selection headache and this one. In > >> the antenna case, there isn't a good value that you can set that will > >> work on all systems. If you change the default behaviour you will > >> solve the issue for some users while simultanously introducing the > >> problem on other systems that were previously fine. > >> > >> However in this case, it's highly likely that setting aspm=0 (off) by > >> default would work for everyone. It has the disadvantage of using a > >> bit more power, but especially with the indications that this issue > >> affects a significant number of systems, I think that having the > >> driver working out of the box everywhere is more important. The module > >> parameter can be left in place so that unaffected users that want to > >> save power can set aspm=1. > >> > > > > I think this issue may be due to L1 latency, so below patch would be > > helpful but not sure because I don't have the same laptop. > > Is there anyone can help to test? > > I do not know why I cannot apply this patch directly. So, I apply > each line manually. > > However, here is a good news. I tested this fix, and it works > correctly on ASUS X530UN. System can scan and get the access points > list. Finally, it also connects to the access point. > Maybe, you can have a formal patch for this. > That's good news. What does the "dmesg | grep r8822be" say now? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP
2018-07-05 15:36 GMT+08:00 Pkshih : > On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote: >> On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger >> wrote: >> > We will have to agree to disagree. >> > >> > I have no idea what the vendors are doing that cause some motherboards to >> > need a different aspm value. What I do know is that we have had to live >> > with >> > the idiocy of some vendors saving a few pennies by only including a single >> > antenna, rather than two, and then making a problem by miscoding the EFUSE >> > bit that indicates which connector is actually in use. As we have no means >> > that I know about to detect which boxes have the problem, a module >> > parameter >> > was created, just as in this case. >> > >> > I agree that drivers should work "out of the box", but finite resources and >> > lack of vendor cooperation make this a goal that may not be attainable. >> >> As you touched on, the ideal situation is that Realtek solve the >> issue. Ping-Ke Shih is on CC and I am adding a few more contacts from >> the commit log. The context is that the r8822 driver fails on several >> platforms unless setting aspm=0 (the default is 1). > > It's hard to have all laptop or motherboards and all rtl8822be modules in my > side, > so what I can do is to analyze the issue when user encountered. > >> >> https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba >> https://bugzilla.kernel.org/show_bug.cgi?id=199651 >> >> >> If we don't get a timely fix from Realtek though, I think there is a >> key difference between the antenna selection headache and this one. In >> the antenna case, there isn't a good value that you can set that will >> work on all systems. If you change the default behaviour you will >> solve the issue for some users while simultanously introducing the >> problem on other systems that were previously fine. >> >> However in this case, it's highly likely that setting aspm=0 (off) by >> default would work for everyone. It has the disadvantage of using a >> bit more power, but especially with the indications that this issue >> affects a significant number of systems, I think that having the >> driver working out of the box everywhere is more important. The module >> parameter can be left in place so that unaffected users that want to >> save power can set aspm=1. >> > > I think this issue may be due to L1 latency, so below patch would be > helpful but not sure because I don't have the same laptop. > Is there anyone can help to test? I do not know why I cannot apply this patch directly. So, I apply each line manually. However, here is a good news. I tested this fix, and it works correctly on ASUS X530UN. System can scan and get the access points list. Finally, it also connects to the access point. Maybe, you can have a formal patch for this. Thanks, Jian-Hong Pan > > diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c > b/drivers/staging/rtlwifi/rtl8822be/hw.c > index 7947edb239a1..88ba5b2fea6a 100644 > --- a/drivers/staging/rtlwifi/rtl8822be/hw.c > +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c > @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct > ieee80211_hw *hw) > return; > > pci_read_config_byte(rtlpci->pdev, 0x70f, ); > - pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7)); > + pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << > 3); > > pci_read_config_byte(rtlpci->pdev, 0x719, ); > pci_write_config_byte(rtlpci->pdev, 0x719, tmp | BIT(3) | BIT(4)); > diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h > index 012fb618840b..a45f0eb69d3f 100644 > --- a/drivers/staging/rtlwifi/wifi.h > +++ b/drivers/staging/rtlwifi/wifi.h > @@ -88,6 +88,7 @@ > #define RTL_USB_MAX_RX_COUNT 100 > #define QBSS_LOAD_SIZE 5 > #define MAX_WMMELE_LENGTH 64 > +#define ASPM_L1_LATENCY7 > > #define TOTAL_CAM_ENTRY32 > > > --- > PK > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: fix static checker warning to unlock mutex in wilc_deinit()
On Thu, Jul 05, 2018 at 09:18:53AM +0530, Ajay Singh wrote:
> Fix for static checker warning inconsistent returns of
> 'hif_deinit_lock'(more details [1]).
>
> "drivers/staging/wilc1000/host_interface.c:3390 wilc_deinit()
> warn: inconsistent returns 'hif_deinit_lock'."
>
> Introduced in "ff52a57a7a42: staging: wilc1000: move the allocation of
> cmd out of wilc_enqueue_cmd()".
Can you use the Fixes tag so it's machine parseable?
Fixes: ff52a57a7a42 ("staging: wilc1000: move the allocation of cmd out of
wilc_enqueue_cmd()")
With the fixes tag, say someone pulls ff52a57a7a42 into their code, they
will know to pull this patch as well. Also scientists will be able to
measure the time between bug and fix and write a scholarly paper about
it.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [BUG] staging: r8822be: RTL8822be can't find any wireless AP
On Wed, 2018-07-04 at 10:33 -0500, Daniel Drake wrote: > On Wed, Jul 4, 2018 at 10:13 AM, Larry Finger > wrote: > > We will have to agree to disagree. > > > > I have no idea what the vendors are doing that cause some motherboards to > > need a different aspm value. What I do know is that we have had to live with > > the idiocy of some vendors saving a few pennies by only including a single > > antenna, rather than two, and then making a problem by miscoding the EFUSE > > bit that indicates which connector is actually in use. As we have no means > > that I know about to detect which boxes have the problem, a module parameter > > was created, just as in this case. > > > > I agree that drivers should work "out of the box", but finite resources and > > lack of vendor cooperation make this a goal that may not be attainable. > > As you touched on, the ideal situation is that Realtek solve the > issue. Ping-Ke Shih is on CC and I am adding a few more contacts from > the commit log. The context is that the r8822 driver fails on several > platforms unless setting aspm=0 (the default is 1). It's hard to have all laptop or motherboards and all rtl8822be modules in my side, so what I can do is to analyze the issue when user encountered. > > https://gist.github.com/dsd/20c05f0c6d66ee2ef9bfbb17f93f18ba > https://bugzilla.kernel.org/show_bug.cgi?id=199651 > > > If we don't get a timely fix from Realtek though, I think there is a > key difference between the antenna selection headache and this one. In > the antenna case, there isn't a good value that you can set that will > work on all systems. If you change the default behaviour you will > solve the issue for some users while simultanously introducing the > problem on other systems that were previously fine. > > However in this case, it's highly likely that setting aspm=0 (off) by > default would work for everyone. It has the disadvantage of using a > bit more power, but especially with the indications that this issue > affects a significant number of systems, I think that having the > driver working out of the box everywhere is more important. The module > parameter can be left in place so that unaffected users that want to > save power can set aspm=1. > I think this issue may be due to L1 latency, so below patch would be helpful but not sure because I don't have the same laptop. Is there anyone can help to test? diff --git a/drivers/staging/rtlwifi/rtl8822be/hw.c b/drivers/staging/rtlwifi/rtl8822be/hw.c index 7947edb239a1..88ba5b2fea6a 100644 --- a/drivers/staging/rtlwifi/rtl8822be/hw.c +++ b/drivers/staging/rtlwifi/rtl8822be/hw.c @@ -803,7 +803,7 @@ static void _rtl8822be_enable_aspm_back_door(struct ieee80211_hw *hw) return; pci_read_config_byte(rtlpci->pdev, 0x70f, ); - pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | BIT(7)); + pci_write_config_byte(rtlpci->pdev, 0x70f, tmp | ASPM_L1_LATENCY << 3); pci_read_config_byte(rtlpci->pdev, 0x719, ); pci_write_config_byte(rtlpci->pdev, 0x719, tmp | BIT(3) | BIT(4)); diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h index 012fb618840b..a45f0eb69d3f 100644 --- a/drivers/staging/rtlwifi/wifi.h +++ b/drivers/staging/rtlwifi/wifi.h @@ -88,6 +88,7 @@ #define RTL_USB_MAX_RX_COUNT 100 #define QBSS_LOAD_SIZE 5 #define MAX_WMMELE_LENGTH 64 +#define ASPM_L1_LATENCY7 #define TOTAL_CAM_ENTRY32 --- PK ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-gpio: fix problem using one node in DT
On Thu, Jul 05, 2018 at 04:27:31PM +1000, NeilBrown wrote: > On Thu, Jul 05 2018, Sergio Paracuellos wrote: > > > This series fix problem related with the last changes included > > to use only one node in the device tree and some gpio banks > > naming issues. > > > > Hope this helps. > > It sure does. Everything looks and works as expected now. > all: > Reviewed-by: NeilBrown > > Thanks a lot! Thanks to you for your effort and support reviewing this. I think we are ready for a new try to get this mainlined. I'll try to do that tonight. Best regards, Sergio Paracuellos > > NeilBrown > > > > > > Best regards, > > Sergio Paracuellos > > > > Sergio Paracuellos (4): > > staging: mt7621-gpio: set irq chip name only once > > staging: mt7621-gpio: use custom xlate function > > staging: mt7621-gpio: assign gpio chip custom changes after bgpio_init > > staging: mt7621-gpio: use devm_kasprintf to set gpio banks labels > > > > drivers/staging/mt7621-gpio/gpio-mt7621.c | 25 ++--- > > 1 file changed, 18 insertions(+), 7 deletions(-) > > > > -- > > 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] staging: mt7621-gpio: fix problem using one node in DT
On Thu, Jul 05 2018, Sergio Paracuellos wrote: > This series fix problem related with the last changes included > to use only one node in the device tree and some gpio banks > naming issues. > > Hope this helps. It sure does. Everything looks and works as expected now. all: Reviewed-by: NeilBrown Thanks a lot! NeilBrown > > Best regards, > Sergio Paracuellos > > Sergio Paracuellos (4): > staging: mt7621-gpio: set irq chip name only once > staging: mt7621-gpio: use custom xlate function > staging: mt7621-gpio: assign gpio chip custom changes after bgpio_init > staging: mt7621-gpio: use devm_kasprintf to set gpio banks labels > > drivers/staging/mt7621-gpio/gpio-mt7621.c | 25 ++--- > 1 file changed, 18 insertions(+), 7 deletions(-) > > -- > 2.7.4 signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: mt7621-gpio: use devm_kasprintf to set gpio banks labels
Instead of using a custom function to return desired name for gpio
use the default assigned one and concat it '-bankN' suffix using
devm_kasprintf kernel function.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 1b4588a..d7256b5 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -196,15 +196,6 @@ static struct irq_chip mediatek_gpio_irq_chip = {
.irq_set_type = mediatek_gpio_irq_type,
};
-static inline const char * const mediatek_gpio_bank_name(int bank)
-{
- static const char * const bank_names[] = {
- "mt7621-bank0", "mt7621-bank1", "mt7621-bank2",
- };
-
- return bank_names[bank];
-}
-
static int
mediatek_gpio_xlate(struct gpio_chip *chip,
const struct of_phandle_args *spec, u32 *flags)
@@ -251,7 +242,8 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
rg->chip.of_gpio_n_cells = 2;
rg->chip.of_xlate = mediatek_gpio_xlate;
- rg->chip.label = mediatek_gpio_bank_name(rg->bank);
+ rg->chip.label = devm_kasprintf(>dev, GFP_KERNEL, "%s-bank%d",
+ dev_name(>dev), bank);
ret = devm_gpiochip_add_data(>dev, >chip, gpio);
if (ret < 0) {
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: mt7621-gpio: use custom xlate function
The default gpio.of_xlate function assumes there is one gpio chip
for each devicetree node. Device tree had changed to only use one node,
which corresponds to 3 different gpio chips now. For that approach
to work we need a custom xlate function.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 06024a3..ccf2aa8 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -206,6 +206,22 @@ static inline const char * const
mediatek_gpio_bank_name(int bank)
}
static int
+mediatek_gpio_xlate(struct gpio_chip *chip,
+ const struct of_phandle_args *spec, u32 *flags)
+{
+ int gpio = spec->args[0];
+ struct mtk_gc *rg = to_mediatek_gpio(chip);
+
+ if (rg->bank != gpio / MTK_BANK_WIDTH)
+ return -EINVAL;
+
+ if (flags)
+ *flags = spec->args[1];
+
+ return gpio % MTK_BANK_WIDTH;
+}
+
+static int
mediatek_gpio_bank_probe(struct platform_device *pdev,
struct device_node *node, int bank)
{
@@ -220,6 +236,8 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
spin_lock_init(>lock);
rg->chip.of_node = node;
rg->bank = bank;
+ rg->chip.of_gpio_n_cells = 2;
+ rg->chip.of_xlate = mediatek_gpio_xlate;
rg->chip.label = mediatek_gpio_bank_name(rg->bank);
dat = gpio->gpio_membase + GPIO_REG_DATA + (rg->bank * GPIO_BANK_WIDE);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: mt7621-gpio: set irq chip name only once
There is only one irq chip so set its name only once
in driver probe function.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 281e621..06024a3 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -257,7 +257,6 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
return ret;
}
- mediatek_gpio_irq_chip.name = rg->chip.label;
ret = gpiochip_irqchip_add(>chip, _gpio_irq_chip,
0, handle_simple_irq, IRQ_TYPE_NONE);
if (ret) {
@@ -296,6 +295,7 @@ mediatek_gpio_probe(struct platform_device *pdev)
gpio_data->gpio_irq = irq_of_parse_and_map(np, 0);
gpio_data->dev = >dev;
platform_set_drvdata(pdev, gpio_data);
+ mediatek_gpio_irq_chip.name = dev_name(>dev);
for (i = 0; i < MTK_BANK_CNT; i++)
mediatek_gpio_bank_probe(pdev, np, i);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: mt7621-gpio: assign gpio chip custom changes after bgpio_init
bgpio_init function set different data of the gpio chip, like the name.
We want specific name for each bank so to get that not overwritten
move all custom changes after the bgpio_init function call.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index ccf2aa8..1b4588a 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -236,9 +236,6 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
spin_lock_init(>lock);
rg->chip.of_node = node;
rg->bank = bank;
- rg->chip.of_gpio_n_cells = 2;
- rg->chip.of_xlate = mediatek_gpio_xlate;
- rg->chip.label = mediatek_gpio_bank_name(rg->bank);
dat = gpio->gpio_membase + GPIO_REG_DATA + (rg->bank * GPIO_BANK_WIDE);
set = gpio->gpio_membase + GPIO_REG_DSET + (rg->bank * GPIO_BANK_WIDE);
@@ -252,6 +249,10 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
return ret;
}
+ rg->chip.of_gpio_n_cells = 2;
+ rg->chip.of_xlate = mediatek_gpio_xlate;
+ rg->chip.label = mediatek_gpio_bank_name(rg->bank);
+
ret = devm_gpiochip_add_data(>dev, >chip, gpio);
if (ret < 0) {
dev_err(>dev, "Could not register gpio %d, ret=%d\n",
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: mt7621-gpio: fix problem using one node in DT
This series fix problem related with the last changes included to use only one node in the device tree and some gpio banks naming issues. Hope this helps. Best regards, Sergio Paracuellos Sergio Paracuellos (4): staging: mt7621-gpio: set irq chip name only once staging: mt7621-gpio: use custom xlate function staging: mt7621-gpio: assign gpio chip custom changes after bgpio_init staging: mt7621-gpio: use devm_kasprintf to set gpio banks labels drivers/staging/mt7621-gpio/gpio-mt7621.c | 25 ++--- 1 file changed, 18 insertions(+), 7 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
