On Sat, Feb 27, 2021 at 2:17 AM Bjorn Helgaas wrote:
>
> On Fri, Feb 26, 2021 at 02:31:31PM +0100, Heiner Kallweit wrote:
> > On 26.02.2021 13:18, Kai-Heng Feng wrote:
> > > On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit
> > > wrote:
> > >>
&g
On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit wrote:
>
> On 26.02.2021 08:12, Kalle Valo wrote:
> > Kai-Heng Feng writes:
> >
> >> Now we have a generic D3 shutdown quirk, so convert the original
> >> approach to a PCI quirk.
> >>
> >> Si
Now we have a generic D3 shutdown quirk, so convert the original
approach to a PCI quirk.
Signed-off-by: Kai-Heng Feng
---
drivers/net/wireless/realtek/rtw88/pci.c | 2 --
drivers/pci/quirks.c | 6 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers
On Tue, Feb 2, 2021 at 3:02 PM Larry Finger wrote:
>
> On 2/2/21 12:29 AM, Kalle Valo wrote:
> > Kai-Heng Feng writes:
> >
> >> On Wed, Aug 5, 2020 at 7:24 PM Kai-Heng Feng
> >> wrote:
> >>>
> >>> Hi Tony,
> >>>
> >&g
According to the vendor driver, the new chip with XID 0x54b is
essentially the same as the one with XID 0x54a, but it doesn't need the
firmware.
So add support accordingly.
Signed-off-by: Kai-Heng Feng
---
v2:
- Add phy support.
- Rebase on net-next.
drivers/net/ethernet/realtek/r8
On Tue, Feb 2, 2021 at 2:54 AM Heiner Kallweit wrote:
>
> On 01.02.2021 17:47, Kai-Heng Feng wrote:
> > According to the vendor driver, the new chip with XID 0x54b is
> > essentially the same as the one with XID 0x54a, but it doesn't need the
> > firmware.
>
According to the vendor driver, the new chip with XID 0x54b is
essentially the same as the one with XID 0x54a, but it doesn't need the
firmware.
So add support accordingly.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/realtek/r8169.h | 1 +
drivers/net/ethernet/re
On Wed, Aug 5, 2020 at 7:24 PM Kai-Heng Feng
wrote:
>
> Hi Tony,
>
> > On Aug 5, 2020, at 19:18, Tony Chuang wrote:
> >
> >> 8821CE with RFE 2 isn't supported:
> >> [ 12.404834] rtw_8821ce :02:00.0: rfe 2 isn't supported
> >> [
88 usecs
>
> After the patch:
> echo disabled > //sys/devices/pci\:00/\:00\:19.0/power/wakeup
> becomes 0 usecs because the hooks will be skipped.
>
> Suggested-by: Kai-Heng Feng
> Signed-off-by: Chen Yu
Well, I was intended to send it, but anyway :)
> ---
&
wever, igc is like igb, runtime resume routine
uses rtnl_lock() which upper ethtool layer also uses.
So to prevent a deadlock on rtnl, take a different approach, use
pm_runtime_suspended() to avoid reading register while device is runtime
suspended.
Cc:
Signed-off-by: Kai-Heng Feng
---
drivers/
Hi Vitaly,
> On Sep 30, 2020, at 14:54, Vitaly Lifshits wrote:
>
> On 9/29/2020 18:08, Kai-Heng Feng wrote:
>
> Hello Kai-Heng,
>>> On Sep 29, 2020, at 21:46, Neftin, Sasha wrote:
>>>
>>> Hello Kai-Heng,
>>> On 9/29/2020 16:31, Kai-Heng Feng
> On Sep 29, 2020, at 23:11, David Laight wrote:
>
>> Hope we finally have proper ME support under Linux?
>
> How about a way to disable it.
This will do, too :)
Kai-Heng
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Regist
> On Sep 29, 2020, at 21:46, Neftin, Sasha wrote:
>
> Hello Kai-Heng,
> On 9/29/2020 16:31, Kai-Heng Feng wrote:
>> Hi Sasha,
>>> On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
>>>
>>> On 9/28/2020 11:36, Kai-Heng Feng wrote:
>>&
Hi Sasha,
> On Sep 29, 2020, at 21:08, Neftin, Sasha wrote:
>
> On 9/28/2020 11:36, Kai-Heng Feng wrote:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1000e :00:1f.6 eno1:
2984
Signed-off-by: Kai-Heng Feng
---
v2:
- Add more detail in commit log.
drivers/net/wireless/realtek/rtw88/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/drivers/net/wireless/realtek/rtw88/pci.c
index 3413973bc475..7f1f5073b9f4 100644
--
flict with software.
Signed-off-by: Kai-Heng Feng
---
v4:
- States that this patch just papers over the symptom.
v3:
- Moving delay to end of loop doesn't save anytime, move it back.
- Point out this is quitely likely caused by Intel ME.
v2:
- Increase polling iteration instead of powerin
> On Sep 25, 2020, at 03:57, Andrew Lunn wrote:
>
> On Fri, Sep 25, 2020 at 12:45:42AM +0800, Kai-Heng Feng wrote:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1000e :
As Andrew Lunn pointed out, MDIO has nothing to do with phy, and indeed
increase polling iteration can resolve the issue.
The root cause is quite likely Intel ME, since it's a blackbox to the
kernel so the only approach we can take is to be patient and wait
longer.
Signed-off-by: Kai-Heng
Hi Andrew,
> On Sep 24, 2020, at 23:53, Andrew Lunn wrote:
>
> On Thu, Sep 24, 2020 at 11:09:58PM +0800, Kai-Heng Feng wrote:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1
As Andrew Lunn pointed out, MDIO has nothing to do with phy, and indeed
increase polling iteration can resolve the issue.
While at it, also move the delay to the end of loop, to potentially save
50 us.
Signed-off-by: Kai-Heng Feng
---
v2:
- Increase polling iteration instead of powering down the
Hi Andrew,
> On Sep 23, 2020, at 23:37, Andrew Lunn wrote:
>
> On Wed, Sep 23, 2020 at 10:44:10PM +0800, Kai-Heng Feng wrote:
>> Hi Andrew,
>>
>>> On Sep 23, 2020, at 20:17, Andrew Lunn wrote:
>>>
>>> On Wed, Sep 23, 2020 at 03:47:51PM +0
because EAPOL hasn't finished. Increase the session protection
duration to 1200TU can eliminate the problem.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=209237
Signed-off-by: Kai-Heng Feng
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 ++--
1 file changed, 2 insertions(
Hi Paul,
> On Sep 23, 2020, at 21:28, Paul Menzel wrote:
>
> Dear Kai-Heng,
>
>
> Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.8
Hi Andrew,
> On Sep 23, 2020, at 20:17, Andrew Lunn wrote:
>
> On Wed, Sep 23, 2020 at 03:47:51PM +0800, Kai-Heng Feng wrote:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1
Since we don't know what platform firmware may do to the phy, so let's
power cycle the phy upon system resume to resolve the issue.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/in
> On Aug 26, 2020, at 08:27, Brian Norris wrote:
>
> On Mon, Aug 24, 2020 at 2:32 AM Kai-Heng Feng
> wrote:
>>
>> Sometimes system freeze on cold/warm boot when rtw88 is probing.
>>
>> According to [1], platform firmware may not properly power manage
to D3 at shutdown
to prevent the issue from happening.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=206411#c9
Signed-off-by: Kai-Heng Feng
---
drivers/net/wireless/realtek/rtw88/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
b/driver
Hi Tony,
> On Aug 5, 2020, at 19:18, Tony Chuang wrote:
>
>> 8821CE with RFE 2 isn't supported:
>> [ 12.404834] rtw_8821ce :02:00.0: rfe 2 isn't supported
>> [ 12.404937] rtw_8821ce :02:00.0: failed to setup chip efuse info
>> [ 12.404939] rtw_8821ce :02:00.0: failed to setup c
se, so add it to the RFE
default.
Signed-off-by: Kai-Heng Feng
---
drivers/net/wireless/realtek/rtw88/rtw8821c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
index d8863d8a5468..f7270d0f1d55 10
> On Jul 18, 2020, at 01:34, Chuck Lever wrote:
>
>
>
>> On Jul 17, 2020, at 1:29 PM, Pierre Sauter wrote:
>>
>> Hi Chuck,
>>
>> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever:
>>> So this makes me think there's a possibility you are not using upstream
>>> stable kernels.
> On Jul 15, 2020, at 23:02, Chuck Lever wrote:
>
>
>
>> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng
>> wrote:
>>
>> Hi,
>>
>> Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu,
>> due to commit &qu
Hi,
Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu, due
to commit "SUNRPC: Add "@len" parameter to gss_unwrap()" and commit "SUNRPC:
Fix GSS privacy computation of auth->au_ralign".
The same issue happens on upstream stable 5.4.y branch.
The mainline kernel doesn't ha
> On Jul 7, 2020, at 16:46, Alexander Lobakin wrote:
>
> From: Kai-Heng Feng
> Date: Tue, 7 Jul 2020 14:38:28 +0800
>
>> We have a new ethernet card that is supported by the atlantic driver:
>> 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-
kernel: atlantic: probe of :01:00.0 failed with error -95
As a pure guesswork, simply adding the firmware version to the driver
can make it function. Doing iperf3 as a smoketest doesn't show any
abnormality either.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/aquantia/atlantic/h
> On Jun 16, 2020, at 18:05, Aaron Ma wrote:
>
> After commit "e1000e: disable s0ix entry and exit flows for ME systems",
> some ThinkPads always failed to disable ulp by ME.
> commit "e1000e: Warn if disabling ULP failed" break out of init phy:
>
> error log:
> [ 42.364753] e1000e :00:
let's disable TSO by default to regain the loss.
Fixes: b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing
DMA transactions")
BugLink: https://bugs.launchpad.net/bugs/1802691
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/e1000e/netdev.c | 4
The hardware may stop working if driver failed to disable ULP mode.
Take the return value of e1000_disable_ulp_lpt_lp() into account, and
pass up the error if it fails.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 6 +-
1 file changed, 5 insertions(+), 1
, begin()
calls igb_runtime_resume() , which tries to rtnl_lock() while the lock
is already hold by upper ethtool layer.
So let's take this approach until the igb_runtime_resume() no longer
needs to hold rtnl_lock.
Cc: Jeff Kirsher
Cc: Aaron Brown
Suggested-by: Alexander Duyck
Signed-off-by: K
es to rtnl_lock() while the lock
is already hold by upper ethtool layer.
So let's take this approach until the igb_runtime_resume() no longer
needs to hold rtnl_lock.
Suggested-by: Alexander Duyck
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 6 ++
1 file c
Hi Siva,
at 21:42, Siva Reddy Kallam wrote:
On Mon, Mar 11, 2019 at 9:23 AM Kai-Heng Feng
wrote:
[snipped]
Hi again,
Any update?
Kai-Heng
Sorry for the late reply. We will provide our feedback soon.
Any good news? It still happens on latest mainline kernel.
Kai-Heng
[snipped]
Hi again,
Any update?
Kai-Heng
kable MSI are not supported by this device, fallback
to use INTx on affected platforms.
BugLink: https://bugs.launchpad.net/bugs/1807259
BugLink: https://bugs.launchpad.net/bugs/1809843
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/marvell/sky2.c | 24 +++-
1 file change
Another platform requires even longer delay to make the device work
correctly after S3.
So increase the delay to 300ms.
BugLink: https://bugs.launchpad.net/bugs/1798921
Cc: sta...@vger.kernel.org
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/marvell/sky2.c | 2 +-
1 file changed, 1
> On Feb 4, 2019, at 6:20 PM, Bjorn Helgaas wrote:
>
> On Sun, Feb 03, 2019 at 01:46:50AM +0800, Kai Heng Feng wrote:
>>> On Jan 28, 2019, at 3:51 PM, Kai Heng Feng
>>> wrote:
>>
>>>> If I understand correctly, the bugzilla lspci
>>>&
Hi Bjorn,
> On Jan 28, 2019, at 3:51 PM, Kai Heng Feng
> wrote:
[snipped]
>> If I understand correctly, the bugzilla lspci
>> (https://bugzilla.kernel.org/attachment.cgi?id=280691) was collected
>> at point 8, and it shows PME_Status=1 when it should be 0.
>>
&g
https://bugzilla.kernel.org/attachment.cgi?id=280819
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 189f231
Hi tg3 folks,
> On Jan 9, 2019, at 13:42, Kai Heng Feng wrote:
>
>
>
>> On Jan 7, 2019, at 5:12 PM, Siva Reddy Kallam
>> wrote:
>>
>> On Mon, Jan 7, 2019 at 11:34 AM Kai Heng Feng
>> wrote:
>>>
>>> Hi tg3 folks,
>>>
&
> On Jan 25, 2019, at 4:05 AM, Bjorn Helgaas wrote:
>
> On Thu, Jan 24, 2019 at 11:29:37PM +0800, Kai Heng Feng wrote:
>>> On Jan 24, 2019, at 11:15 PM, Bjorn Helgaas wrote:
>>> On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
>>>>>
> On Jan 24, 2019, at 11:15 PM, Bjorn Helgaas wrote:
>
> On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
>>> On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas wrote:
>>> On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
>>>> Th
> On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas wrote:
>
> On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
>> There are some e1000e devices can only be woken up from D3 one time, by
>> plugging ethernet cable. Subsequent cable plugging does set PME bit
>&
> On Jan 22, 2019, at 14:45, Kai-Heng Feng wrote:
>
> There are some e1000e devices can only be woken up from D3 one time, by
> plugging ethernet cable. Subsequent cable plugging does set PME bit
> correctly, but it still doesn't get woken up.
>
> Since e1000e co
from _PRW only works once and stops
working after that.
So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
platform firmwares that have unreliable GPE wake.
Signed-off-by: Kai-Heng Feng
---
drivers/pci/pci-acpi.c | 2 +-
drivers/pci/quirks.c | 8
include/linux/
> On Jan 7, 2019, at 5:12 PM, Siva Reddy Kallam
> wrote:
>
> On Mon, Jan 7, 2019 at 11:34 AM Kai Heng Feng
> wrote:
>>
>> Hi tg3 folks,
>>
>> Any idea how to solve the bug?
>>
>> Kai-Heng
> Hi,
> Can you share Register dump(ethto
> On Jan 7, 2019, at 12:13, Mark Lord wrote:
>
> On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>>
>>
>>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>>
>>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>>>> On 2019-01-06 2:14 p.
Hi tg3 folks,
Any idea how to solve the bug?
Kai-Heng
> On Dec 7, 2018, at 17:27, Kai Heng Feng wrote:
>
> Hi tg3 maintainers,
>
> I’ve encountered network freeze when using tg3 in gigabits net.
>
> The issue can be easily reproduced when using scp to transfer file
> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>
> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
>> Mark Lord
>> wrote:
>> ..
>>>> There is even now a special hack
> On Jan 5, 2019, at 10:14 PM, Mark Lord wrote:
>
> A couple of years back, I reported data corruption resulting from
> a change in kernel 3.16 which enabled hardware checksums in the r8152 driver.
> This was happening on an embedded system that was using a r8152 USB dongle.
>
> At the time,
There are two new Realtek Ethernet devices which are re-branded r8168h.
Add the IDs to to support them.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/realtek/r8169.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet
> On Dec 20, 2018, at 14:42, Kalle Valo wrote:
>
> Kai-Heng Feng wrote:
>
>> Once BSS STA mode gets started, it can be scanned by other clients but
>> cannot entablish a connection.
>>
>> Turns out the set_bcn_reg() and its *_set_beacon_related_register
> On Dec 13, 2018, at 15:39, Pkshih wrote:
>
> On Thu, 2018-12-13 at 13:36 +0800, Kai Heng Feng wrote:
>>> On Dec 13, 2018, at 08:35, Pkshih wrote:
>>>
>>> On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote:
>>>> Once BSS STA mode gets
> On Dec 13, 2018, at 08:35, Pkshih wrote:
>
> On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote:
>> Once BSS STA mode gets started, it can be scanned by other clients but
>> cannot entablish a connection.
> ^^^ typo: establish
>>
>>
mode
start to work.
Signed-off-by: Kai-Heng Feng
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
b/drivers/net/wireless/realtek/rtlwifi/core.c
index 4bf7967590ca..11d27a5cc576 100644
e1000e always use suspend callback to set correct WoL during system
suspend.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
always use suspend callback to set correct WoL during system
suspend.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/igb/igb_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index
Hi tg3 maintainers,
I’ve encountered network freeze when using tg3 in gigabits net.
The issue can be easily reproduced when using scp to transfer files in local
network.
The symptom is pretty similar to what this commit is trying to solve:
commit 3a498606bb04af603a46ebde8296040b2de350d1
Author:
(), which enables the PCI PME.
To fix the issue, let's not to save PCI states when it's runtime
suspend, to let the PCI subsytem enables PME.
Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3")
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/in
dition to clearing RTL_FLAG_TASK_ENABLED, also clears other
flags.
Cc: Heiner Kallweit
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/realtek/r8169.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
Hi Satish,
> On 2018Mar21, at 00:57, Kai-Heng Feng wrote:
>
> Satish Baddipadige wrote:
>
>> On Thu, Feb 15, 2018 at 7:37 PM, Siva Reddy Kallam
>> wrote:
>>> On Mon, Feb 12, 2018 at 10:59 AM, Siva Reddy Kallam
>>> wrote:
>>>> On F
-by: Kai-Heng Feng
---
drivers/net/ethernet/marvell/sky2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index 9fe85300e7b6..5754116a6a4d 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers
Kai Heng Feng wrote:
Hopefully Hayes (or Realtek) can shed more lights on the issue. Apparently
ALDPS and ASPM for r8169 is enabled in different commercial products, just
not in Linux mainline.
Hayes and Realtek folks,
How do we make this patch going forward?
Do you find the root cause that
Satish Baddipadige wrote:
On Thu, Feb 15, 2018 at 7:37 PM, Siva Reddy Kallam
wrote:
On Mon, Feb 12, 2018 at 10:59 AM, Siva Reddy Kallam
wrote:
On Fri, Feb 9, 2018 at 10:41 AM, Kai Heng Feng
wrote:
Hi Broadcom folks,
We are now enabling a new platform with tg3 nic, unfortunately we
> On 10 Feb 2018, at 10:05 PM, Felix Fietkau wrote:
>
> On 2018-02-10 14:56, Kai Heng Feng wrote:
>>
>>> On 9 Feb 2018, at 3:16 PM, Kalle Valo wrote:
>>> Sure, but we have to make sure that we don't create regressions on
>>> existing systems.
> On 9 Feb 2018, at 3:16 PM, Kalle Valo wrote:
> Sure, but we have to make sure that we don't create regressions on
> existing systems. For example, did you test this with any system which
> don't support btcoex? (just asking, haven't tested this myself)
No not really, but I will definitely test
Hi Broadcom folks,
We are now enabling a new platform with tg3 nic, unfortunately we observed
the bug [1] that dated back to 2015.
I tried commit 4419bb1cedcd ("tg3: Add workaround to restrict 5762 MRRS to
2048”) but it does’t work.
Do you have any idea how to solve the issue?
[1] https://
Hi Felix,
On Feb 8, 2018, at 7:02 PM, Felix Fietkau wrote:
On 2018-02-08 06:28, Kai-Heng Feng wrote:
Without btcoex_enable, WiFi activies make both WiFi and Bluetooth
unstable if there's a bluetooth connection.
Enable this option when bt_ant_diversity is disabled.
BugLink:
Without btcoex_enable, WiFi activies make both WiFi and Bluetooth
unstable if there's a bluetooth connection.
Enable this option when bt_ant_diversity is disabled.
BugLink: https://bugs.launchpad.net/bugs/1746164
Signed-off-by: Kai-Heng Feng
---
drivers/net/wireless/ath/ath9k/init.c
> On 18 Jan 2018, at 10:50 PM, David Miller wrote:
>
> From: Hayes Wang
> Date: Thu, 18 Jan 2018 03:04:08 +
>
>> [...]
r8153 on Dell TB15/16 dock corrupts rx packets.
This change is suggested by Realtek. They guess that the XHCI
controller doesn't have enough buffer,
> On 18 Jan 2018, at 11:04 AM, Hayes Wang wrote:
>
> [...]
>>> r8153 on Dell TB15/16 dock corrupts rx packets.
>>>
>>> This change is suggested by Realtek. They guess that the XHCI
>>> controller doesn't have enough buffer, and their guesswork is correct,
>>> once the RX aggregation gets disabl
Mario Limonciello
Signed-off-by: Kai-Heng Feng
---
v2:
- Disable RX aggregation instead of disable RX checksum
- Use bcdDevice and iSerialNumber to uniquely identify Dell TB16
drivers/net/usb/r8152.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/driver
> On 27 Nov 2017, at 11:13 PM,
> wrote:
>
> This is quite surprising to me too. The externally plugged in r8153 dongle,
> was it connected over type C port or over type A port? AFAIK Type C port is
> actually Alpine ridge pass through port. It is not connected to XHCI
> controller
> or US
> Also the MAC address is different, can you just trigger off of Dell's
> MAC address space instead of the address space of the dongle device?
A really good idea, never thought of this. Thanks for the hint :)
Still, I need to ask Dell folks to get all the answers.
Kai-Heng
> On 24 Nov 2017, at 4:28 PM, Greg KH wrote:
>
> The bcdDevice is different between the dock device and the "real"
> device, why not use that?
Yea, I’ll poke around and see if bcdDevice alone can be a good predicate.
> Then there is still a bug. Who as ASMedia is working on this, have they
>
> On 23 Nov 2017, at 5:24 PM, Greg KH wrote:
>
> On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote:
>>
>> What I want to do here is to finding this connection:
>> Realtek r8153 <-> SMSC hub (USD ID: 0424:5537) <->
>> ASMedia XHCI cont
> On 23 Nov 2017, at 3:58 PM, Greg KH wrote:
>
> On Thu, Nov 23, 2017 at 01:38:38AM -0500, Kai-Heng Feng wrote:
>> r8153 on Dell TB dock corrupts rx packets.
>>
>> The root cause is not found yet, but disabling rx checksumming can
>> workaround the issue. We
.net/bugs/1729674
Cc: Mario Limonciello
Signed-off-by: Kai-Heng Feng
---
drivers/net/usb/r8152.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index d51d9abf7986..58b80b5e7803 100644
---
> On 15 Nov 2017, at 6:53 PM, David Miller wrote:
>
> From: Kai-Heng Feng
> Date: Wed, 15 Nov 2017 04:00:18 -0500
>
>> Commit ("r8169: enable ALDPS for power saving") caused a regression on
>> RTL8168evl/8111evl [1], so it got reverted.
>>
>
6
Cc: Francois Romieu
Cc: Hayes Wang
Cc: Jörg Otte
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/realtek/r8169.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
ind
Cc: Hayes Wang
Cc: Jörg Otte
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/realtek/r8169.c | 58 +---
1 file changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
ind
On Mon, Nov 14, 2016 at 3:34 PM, Kai-Heng Feng
wrote:
> On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman
> wrote:
>> On 10.11.2016 13:22, Oliver Neukum wrote:
>>>
>>> On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
>>>>
>>>> Kai-Heng Fe
Hi,
On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote:
> Oliver Neukum writes:
>
>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>
>>> These problems could very well be caused by running at SuperSpeed
>>> (USB-3) instead of high speed (USB-2).
Yes, it's running at SuperSpeed, on a Kabyl
Hi,
On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote:
> On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote:
>> Sometimes cdc_mbim failed to probe if runtime pm is enabled:
>> [9.305626] cdc_mbim: probe of 2-2:1.12 failed with error -22
>>
>> This can be solv
Sometimes cdc_mbim failed to probe if runtime pm is enabled:
[9.305626] cdc_mbim: probe of 2-2:1.12 failed with error -22
This can be solved by increase its pm usage counter.
Signed-off-by: Kai-Heng Feng
---
drivers/net/usb/usbnet.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion
92 matches
Mail list logo
