From: Chris Chiu
The legacy_httxpowerdiff in rtl8192se is pretty much the same as
the legacy_ht_txpowerdiff for other chips. Use the same name to
keep the consistency.
Signed-off-by: Chris Chiu
---
drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 2 +-
drivers/net/wireless/realtek
From: Chris Chiu
The legacy_httxpowerdiff in rtl8192se is pretty much the same as
the legacy_ht_txpowerdiff for other chips. Use the same name to
keep the consistency.
Signed-off-by: Chris Chiu
---
drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 2 +-
drivers/net/wireless/realtek
On Tue, Sep 8, 2020 at 8:33 PM Chris Chiu wrote:
>
> Hi Sean, Ryder,
> We have an ASUS laptop X532EQ with the wifi module AZWAVE-CB434NF
> which fails to bring up the wifi interface on kernel 5.9.0-rc1. The
> dmesg shows the firmware load error.
>
> [ 25.630850]
Hi Sean, Ryder,
We have an ASUS laptop X532EQ with the wifi module AZWAVE-CB434NF
which fails to bring up the wifi interface on kernel 5.9.0-rc1. The
dmesg shows the firmware load error.
[ 25.630850] mt7615e :2d:00.0: Message -4294967280 (seq 1) timeout
[ 25.630851] mt7615e :2d:00.
Free the skb if usb_submit_urb fails on rx_urb. And free the urb
no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb.
Signed-off-by: Chris Chiu
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a
may need fix. And I think we
can still bring in the dm_watchdog as rtlwifi to improve from the
driver side. Please leave precious comments for my commits and
suggest what I can do better. Or suggest if there's any better idea
to fix this. Thanks.
Signed-off-by: Chris Chiu
---
Notes:
v2:
On Fri, Dec 21, 2018 at 3:22 AM Heiner Kallweit wrote:
>
> On 20.12.2018 10:43, Chris Chiu wrote:
> > On Thu, Dec 20, 2018 at 3:41 AM Heiner Kallweit
> > wrote:
> >>
> >> On 19.12.2018 16:32, Chris Chiu wrote:
> >>> On Wed, Dec 19, 2018 at 4:28 AM
On Thu, Dec 20, 2018 at 3:41 AM Heiner Kallweit wrote:
>
> On 19.12.2018 16:32, Chris Chiu wrote:
> > On Wed, Dec 19, 2018 at 4:28 AM Heiner Kallweit
> > wrote:
> >>
> >> On 18.12.2018 14:25, Chris Chiu wrote:
> >>> On Tue, Dec 18, 2018 at 3:08 AM
On Wed, Dec 19, 2018 at 4:28 AM Heiner Kallweit wrote:
>
> On 18.12.2018 14:25, Chris Chiu wrote:
> > On Tue, Dec 18, 2018 at 3:08 AM Heiner Kallweit
> > wrote:
> >>
> >> On 17.12.2018 14:25, Chris Chiu wrote:
> >>> On Fri, Dec 14, 2018 at 3:37 PM
On Wed, Dec 19, 2018 at 2:22 AM Heiner Kallweit wrote:
>
> On 18.12.2018 14:25, Chris Chiu wrote:
> > On Tue, Dec 18, 2018 at 3:08 AM Heiner Kallweit
> > wrote:
> >>
> >> On 17.12.2018 14:25, Chris Chiu wrote:
> >>> On Fri, Dec 14, 2018 at 3:37 PM
On Tue, Dec 18, 2018 at 3:08 AM Heiner Kallweit wrote:
>
> On 17.12.2018 14:25, Chris Chiu wrote:
> > On Fri, Dec 14, 2018 at 3:37 PM Heiner Kallweit
> > wrote:
> >>
> >> On 14.12.2018 04:33, Chris Chiu wrote:
> >>> On Thu, Dec 13, 2018
On Tue, Dec 18, 2018 at 5:45 AM Heiner Kallweit wrote:
>
> On 17.12.2018 14:25, Chris Chiu wrote:
> > On Fri, Dec 14, 2018 at 3:37 PM Heiner Kallweit
> > wrote:
> >>
> >> On 14.12.2018 04:33, Chris Chiu wrote:
> >>> On Thu, Dec 13, 2018
On Fri, Dec 14, 2018 at 3:37 PM Heiner Kallweit wrote:
>
> On 14.12.2018 04:33, Chris Chiu wrote:
> > On Thu, Dec 13, 2018 at 10:20 AM Chris Chiu wrote:
> >>
> >> Hi,
> >> We got an acer laptop which has a problem with ethernet networking
> >&
On Thu, Dec 13, 2018 at 10:20 AM Chris Chiu wrote:
>
> Hi,
> We got an acer laptop which has a problem with ethernet networking after
> resuming from S3. The ethernet is popular realtek r8168. The lspci shows as
> follows.
> 02:00.1 Ethernet controller [0200]: Realtek Semi
Hi,
We got an acer laptop which has a problem with ethernet networking after
resuming from S3. The ethernet is popular realtek r8168. The lspci shows as
follows.
02:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8
On Fri, Feb 2, 2018 at 7:49 PM, Hau wrote:
>
>> -Original Message-
>> From: Chris Chiu [mailto:c...@endlessm.com]
>> Sent: Friday, February 2, 2018 10:03 AM
>> To: Hau
>> Cc: nic_swsd ; netdev@vger.kernel.org; Linux
>> Kernel ; Linux Upstreaming
On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu wrote:
> On Mon, Jan 29, 2018 at 11:24 PM, Hau wrote:
>> Hi Chris,
>>
>> Could you test following patch?
>>
>> DECLARE_RTL_COND(rtl_ocp_tx_cond)
>> {
>> void __iomem *ioaddr = tp->mmio_
ing for incorrect register bit? Can you help work out a patch for this?
Chris
>> -Original Message-
>> From: Chris Chiu [mailto:c...@endlessm.com]
>> Sent: Monday, January 29, 2018 6:12 PM
>> To: nic_swsd ; netdev@vger.kernel.org; Linux
>> Kernel ; Linux Upstreaming
On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu wrote:
> On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu wrote:
>> Hi,
>> We've hit a suspend/resume issue on a Acer desktop caused by r8169
>> driver. The dmseg
>> https://gist.github.com/mschiu77/b741849b5070281daaea
On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu wrote:
> Hi,
> We've hit a suspend/resume issue on a Acer desktop caused by r8169
> driver. The dmseg
> https://gist.github.com/mschiu77/b741849b5070281daaead8dfee312d1a
> shows it's still in msleep() within a mutex lock.
Hi,
We've hit a suspend/resume issue on a Acer desktop caused by r8169
driver. The dmseg
https://gist.github.com/mschiu77/b741849b5070281daaead8dfee312d1a
shows it's still in msleep() within a mutex lock.
After looking into the code, it's caused by the
rtl8168ep_stop_cmac() which is waiting
21 matches
Mail list logo
