[PATCH] USB: Add reset-resume quirk for WD19's Realtek Hub

[chris . chiu]

From: Chris Chiu 

Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=5487 Rev= 1.47
S:  Manufacturer=Dell Inc.
S:  Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the specified port of the hub. The port
seems to be in an unknown state so the hub_activate during resume
fails the hub_port_status, then the hub will fail to work.

The quirky hub needs the reset-resume quirk to function correctly.

Signed-off-by: Chris Chiu 
---
 drivers/usb/core/quirks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 76ac5d6555ae..4e2483e34250 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -406,6 +406,7 @@ static const struct usb_device_id usb_quirk_list[] = {
 
/* Realtek hub in Dell WD19 (Type-C) */
{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+   { USB_DEVICE(0x0bda, 0x5487), .driver_info = USB_QUIRK_RESET_RESUME },
 
/* Generic RTL8153 based ethernet adapters */
{ USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },
-- 
2.20.1

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Tue, Apr 20, 2021 at 11:28 PM Alan Stern  wrote:
>
> On Tue, Apr 20, 2021 at 03:14:56PM +0800, Chris Chiu wrote:
> > On Mon, Apr 19, 2021 at 10:19 PM Alan Stern  
> > wrote:
> > >
> > > On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote:
> > > > Sorry that I didn't make myself clear. I found that if I applied 
> > > > RESET_RESUME
> > > > quirk on the problematic hub, the Set-Port-Feature(suspend) timeout 
> > > > error
> > > > disappeared. SInce the timeout is not happening for each suspend by 
> > > > default,
> > > > I suspect maybe reset-resume take everything back to clean state for 
> > > > the hub
> > > > and the Set-Port-Feature(suspend) can be taken care of w/o problems.
> > >
> > > Okay, that's a good solution for system suspend.
> > >
> > > > I didn't like RESET_RESUME because runtime PM would not work on the 
> > > > quirked
> > > > device.
> > >
> > > A more interesting question is whether it will work for devices plugged
> > > into the hub.  Even though the hub won't be runtime suspended, the
> > > things attached to it might be.
> > >
> > > >  But if the Set-Port-Feature(suspend) can't be handled and
> > > > skipped, I can't
> > > > expect the runtime PM to work for all devices connected to the hub 
> > > > either.
> > > > Is that right? If what I proposed in the patch can not get better
> > > > result than existing
> > > > quirk, I think using the RESET_RESUME would be a better option. Any 
> > > > suggestions?
> > >
> > > Try the RESET_RESUME quirk and see how well it works with runtime
> > > suspend.
> > >
> > > Alan Stern
> >
> > [  453.064346] usb 3-4: finish reset-resume
> > [  453.192387] usb 3-4: reset high-speed USB device number 2 using xhci_hcd
> > [  453.339916] usb 3-4: USB quirks for this device: 2
>
> Here 3-4 is problematic RealTek hub, right?
Yes.

>
> > Seems that even w/ the RESET_RESUME enabled, the connected device still
> > can runtime suspend/resume. That's acceptable to me. I'll send the patch
> > with the reset-resume quirk later.
> >
> > [  626.081068] usb 3-4.3.1: usb auto-suspend, wakeup 0
> > [  632.552071] usb 3-4.3.1: usb auto-resume
> > [  632.617467] usb 3-4.3.1: Waited 0ms for CONNECT
> > [  632.617471] usb 3-4.3.1: finish resume
>
> Then 3-4.3 is another hub plugged into the Realtek hub, and 3-4.3.1 (the
> device being suspended and resumed) is plugged into that other hub.
>
> I'm concerned about devices that are plugged directly into the Realtek
> hub.  For example, did you try allowing the 3-4.3 hub in the experiment
> above to suspend and resume?
>
> Alan Stern

The WD19 dock has 2 hubs 0bda:5487 (USB3.0) and 0bda:0487 (superspeed).
There're 5 exposed USB ports (3 Type A + 2 Type C). Lower speed ports
connect to a sub-hub (3-4.3) of the problematic hub (3-4).

The other ports such as HDMI/DisplayPort, Gigabit Ethernet and Type C ports
are connected to 0bda:0478. So I can't connect any USB devices directly to hub
3-4. I'm only certain that the direct child (3-4.3) of the hub
0bda:5487 can't runtime
suspend. But what really matters to me is that all connected devices
(3-4.3.x) can
runtime suspend.

Chris

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Mon, Apr 19, 2021 at 10:19 PM Alan Stern  wrote:
>
> On Mon, Apr 19, 2021 at 01:11:38AM -0400, Chris Chiu wrote:
> > Sorry that I didn't make myself clear. I found that if I applied 
> > RESET_RESUME
> > quirk on the problematic hub, the Set-Port-Feature(suspend) timeout error
> > disappeared. SInce the timeout is not happening for each suspend by default,
> > I suspect maybe reset-resume take everything back to clean state for the hub
> > and the Set-Port-Feature(suspend) can be taken care of w/o problems.
>
> Okay, that's a good solution for system suspend.
>
> > I didn't like RESET_RESUME because runtime PM would not work on the quirked
> > device.
>
> A more interesting question is whether it will work for devices plugged
> into the hub.  Even though the hub won't be runtime suspended, the
> things attached to it might be.
>
> >  But if the Set-Port-Feature(suspend) can't be handled and
> > skipped, I can't
> > expect the runtime PM to work for all devices connected to the hub either.
> > Is that right? If what I proposed in the patch can not get better
> > result than existing
> > quirk, I think using the RESET_RESUME would be a better option. Any 
> > suggestions?
>
> Try the RESET_RESUME quirk and see how well it works with runtime
> suspend.
>
> Alan Stern

[  453.064346] usb 3-4: finish reset-resume
[  453.192387] usb 3-4: reset high-speed USB device number 2 using xhci_hcd
[  453.339916] usb 3-4: USB quirks for this device: 2

Seems that even w/ the RESET_RESUME enabled, the connected device still
can runtime suspend/resume. That's acceptable to me. I'll send the patch
with the reset-resume quirk later.

[  626.081068] usb 3-4.3.1: usb auto-suspend, wakeup 0
[  632.552071] usb 3-4.3.1: usb auto-resume
[  632.617467] usb 3-4.3.1: Waited 0ms for CONNECT
[  632.617471] usb 3-4.3.1: finish resume

Chris

Broadcom 9460 raid card takes too long at system resuming

[Chris Chiu]

Hi,
We found that the Broadcom 9460 RAID card will take ~40 seconds in
 megasas_resume. It is mainly waiting for the FW to come to ready
state, please refer to the following kernel log. The FW version is
"megasas: 07.714.04.00-rc1". It seems that the
megasas_transition_to_ready() loop costs ~40 seconds in
megasas_resume. However, the same megasas_transition_to_ready()
function only takes a few milliseconds to complete in
megasas_init_fw(). The .read_fw_status_reg maps to
megasas_read_fw_status_reg_fusion. I tried to add
pci_enable_device_mem() and pci_set_master before
megasas_transition_to_ready() in megasas_resume() but it makes no
difference.

I don't really know what makes the difference between driver probe and
resume. The lspci information of the raid controller is here
https://gist.github.com/mschiu77/e74ec084cc925643add845fa4dc31ab6. Any
suggestions about what I can do to find out the cause? Thanks.

[   62.357688] megaraid_sas :45:00.0: megasas_resume is called
[   62.357719] megaraid_sas :45:00.0: Waiting for FW to come to ready state
[  104.382571] megaraid_sas :45:00.0: FW now in Ready state
[  104.382576] megaraid_sas :45:00.0: 63 bit DMA mask and 63 bit
consistent mask
[  104.383350] megaraid_sas :45:00.0: requested/available msix 33/33
[  104.383669] megaraid_sas :45:00.0: Performance mode :Latency
[  104.383671] megaraid_sas :45:00.0: FW supports sync cache: Yes
[  104.383677] megaraid_sas :45:00.0: megasas_disable_intr_fusion
is called outbound_intr_mask:0x4009
[  104.550570] megaraid_sas :45:00.0: FW provided
supportMaxExtLDs: 1   max_lds: 64
[  104.550574] megaraid_sas :45:00.0: controller type   : MR(4096MB)
[  104.550575] megaraid_sas :45:00.0: Online Controller Reset(OCR)
 : Enabled
[  104.550577] megaraid_sas :45:00.0: Secure JBOD support   : Yes
[  104.550579] megaraid_sas :45:00.0: NVMe passthru support : Yes
[  104.550581] megaraid_sas :45:00.0: FW provided TM
TaskAbort/Reset timeout: 6 secs/60 secs
[  104.550583] megaraid_sas :45:00.0: JBOD sequence map support : Yes
[  104.550585] megaraid_sas :45:00.0: PCI Lane Margining support: No
[  104.550999] megaraid_sas :45:00.0: megasas_enable_intr_fusion
is called outbound_intr_mask:0x4000

Chris

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Fri, Apr 16, 2021 at 11:39 AM Alan Stern  wrote:
>
> On Fri, Apr 16, 2021 at 09:24:30AM +0800, Chris Chiu wrote:
> > On Fri, Apr 16, 2021 at 2:46 AM Alan Stern  
> > wrote:
> > >
> > > On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > > > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > > > problem if I resume by waking up from the keyboard connected to the hub.
> > >
> > > I thought you said earlier that the port got into trouble while it was
> > > suspending, not while it was resuming.  You wrote:
> > >
> > > > [ 2789.679812] usb 3-4-port3: can't suspend, status -110
> > >
> > > So if the problem occurs during suspend, how can it be possible to avoid
> > > the problem by taking some particular action later while resuming?
> > >
> >
> > The ETIMEDOUT is still there, but the port can resume w/o problems and I
> > don't really know what the hub did. I can only reset_resume the hub to 
> > bring it
> > back if I'm not waking up from the connected keyboard.
>
> What if two devices are plugged into the hub, only one of them is
> runtime suspended, and you need to runtime resume that device?  Then you
> can't do a reset-resume of the hub, because the hub isn't suspended.
>
> > > > But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
> > > > of that port while resuming. In normal cases, they are 0507:.
> > >
> > > The 0004 bit of wPortChange means that the suspend status has changed;
> > > the port is no longer suspended because the device attached to that port
> > > (your keyboard) issued a wakeup request.
> > >
> > > >  I don't know how to SetPortFeature() with setting the status change 
> > > > bit only.
> > >
> > > You can't.  Only the hub itself can set the wPortChange bits.
> > >
> > > > Or maybe it's just some kind of timing issue of the
> > > > idle/suspend/resume signaling.
> > >
> > > Not timing.  It's because you woke the system up from the attached
> > > keyboard.
> > >
> > > Alan Stern
> >
> > Got it. I'm just confused by the USB 2.0 spec 11.24.2.7.2 that
> > "Hubs may allow setting of the status change bits with a SetPortFeature()
> >  request for diagnostic purposes."
>
> Yeah, I don't think very many hubs actually do that.
>
> > So for this case, I think USB_QUIRK_RESET_RESUME would be a
> > better option to at least bring back the port. Any suggestion about what
> > kind of test I can do on this hub? Thanks
>
> I'm not sure what you're proposing.
>
> If (as mentioned above) the hub doesn't handle the
> Set-Port-Feature(suspend) request properly, then we should avoid issuing
> that request.  Which means runtime suspend attempts should not be
> allowed, as in your most recent patch.
>
> Alan Stern

Sorry that I didn't make myself clear. I found that if I applied RESET_RESUME
quirk on the problematic hub, the Set-Port-Feature(suspend) timeout error
disappeared. SInce the timeout is not happening for each suspend by default,
I suspect maybe reset-resume take everything back to clean state for the hub
and the Set-Port-Feature(suspend) can be taken care of w/o problems.

I didn't like RESET_RESUME because runtime PM would not work on the quirked
device. But if the Set-Port-Feature(suspend) can't be handled and
skipped, I can't
expect the runtime PM to work for all devices connected to the hub either.
Is that right? If what I proposed in the patch can not get better
result than existing
quirk, I think using the RESET_RESUME would be a better option. Any suggestions?

Chris

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Fri, Apr 16, 2021 at 2:46 AM Alan Stern  wrote:
>
> On Fri, Apr 16, 2021 at 12:13:43AM +0800, Chris Chiu wrote:
> > One thing worth mentioning here, I never hit the hub_ext_port_status -71
> > problem if I resume by waking up from the keyboard connected to the hub.
>
> I thought you said earlier that the port got into trouble while it was
> suspending, not while it was resuming.  You wrote:
>
> > [ 2789.679812] usb 3-4-port3: can't suspend, status -110
>
> So if the problem occurs during suspend, how can it be possible to avoid
> the problem by taking some particular action later while resuming?
>

The ETIMEDOUT is still there, but the port can resume w/o problems and I
don't really know what the hub did. I can only reset_resume the hub to bring it
back if I'm not waking up from the connected keyboard.

> > But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
> > of that port while resuming. In normal cases, they are 0507:.
>
> The 0004 bit of wPortChange means that the suspend status has changed;
> the port is no longer suspended because the device attached to that port
> (your keyboard) issued a wakeup request.
>
> >  I don't know how to SetPortFeature() with setting the status change bit 
> > only.
>
> You can't.  Only the hub itself can set the wPortChange bits.
>
> > Or maybe it's just some kind of timing issue of the
> > idle/suspend/resume signaling.
>
> Not timing.  It's because you woke the system up from the attached
> keyboard.
>
> Alan Stern

Got it. I'm just confused by the USB 2.0 spec 11.24.2.7.2 that
"Hubs may allow setting of the status change bits with a SetPortFeature()
 request for diagnostic purposes."

So for this case, I think USB_QUIRK_RESET_RESUME would be a
better option to at least bring back the port. Any suggestion about what
kind of test I can do on this hub? Thanks

Chris

Re: [PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Thu, Apr 15, 2021 at 8:32 PM Greg KH  wrote:
>
> On Thu, Apr 15, 2021 at 07:48:56PM +0800, chris.c...@canonical.com wrote:
> > From: Chris Chiu 
> >
> > Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
> > after the system resumes from suspend with remote wakeup enabled
> > device connected:
> > [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> > [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
> > [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> > [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
>
> How does other operating systems handle this?  The hardware seems like
> it does not follow the USB spec, how did it get "certified"?
>
I agree. All usb hubs that claim to support Selective Scan should handle
SetPortFeature (PORT_SUSPEND) w/o problems. As I know, the Windows
usb device driver should submit an Idle Request before it's really going to
suspend, and the bus driver will "selectively" suspend the port.

One thing worth mentioning here, I never hit the hub_ext_port_status -71
problem if I resume by waking up from the keyboard connected to the hub.
But the usbcore kernel log shows me wPortStatus: 0503 wPortChane: 0004
of that port while resuming. In normal cases, they are 0507:.
 I don't know how to SetPortFeature() with setting the status change bit only.
Or maybe it's just some kind of timing issue of the
idle/suspend/resume signaling.

Chris

> > Information of this hub:
> > T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
> > D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
> > P:  Vendor=0bda ProdID=5487 Rev= 1.47
> > S:  Manufacturer=Dell Inc.
> > S:  Product=Dell dock
> > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
> > I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> > I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> >
> > The failure results from the ETIMEDOUT by chance when turning on
> > the suspend feature for the target port of the hub. The port
> > will be unresponsive and placed in unknown state. The hub_activate
> > invoked during resume will fail to get the port stautus with -EPROTO.
> > Then all devices connected to the hub will never be found and probed.
> >
> > The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> > "global suspend" in USB 2.0 spec. It's only for many hub devices
> > which don't relay wakeup requests from the devices connected to
> > downstream ports. For this realtek hub, there's no problem waking
> > up the system from connected keyboard.
> >
> > This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.
>
> Can you make this only be allowed for hubs?  But why doesn't the nomal
> "this can not suspend properly" bit work for this?  We have that for
> other USB devices already.
>
> thanks,
>
> greg k-h

[PATCH v3] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[chris . chiu]

From: Chris Chiu 

Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=5487 Rev= 1.47
S:  Manufacturer=Dell Inc.
S:  Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on
the suspend feature for the target port of the hub. The port
will be unresponsive and placed in unknown state. The hub_activate
invoked during resume will fail to get the port stautus with -EPROTO.
Then all devices connected to the hub will never be found and probed.

The USB_PORT_FEAT_SUSPEND is not really necessary due to the
"global suspend" in USB 2.0 spec. It's only for many hub devices
which don't relay wakeup requests from the devices connected to
downstream ports. For this realtek hub, there's no problem waking
up the system from connected keyboard.

This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.

Signed-off-by: Chris Chiu 
---

Changelog:
  v3:
- Do not mislead usbcore that the quirky hub is really suspended.
  return -EIO for quirky hub instead of doing USB_PORT_FEAT_SUSPEND
- Revise the commit message
  v2:
Since the 0bda:5413 is the hub device connects to upstream hub
0bda:5487, the upstream hub which fails the USB_PORT_FEAT_SUSPEND
is the target this patch really wants to quirk.
- Fix the quirk target from the connected hub device to the
  upstream hub
- Correct the usb info of the target hub in the commit message
- Revise the description of the quirk

 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 drivers/usb/core/hub.c  | 10 +++---
 drivers/usb/core/quirks.c   |  5 +
 include/linux/usb/quirks.h  |  3 +++
 4 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..1bb22a9ea5ba 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5682,6 +5682,9 @@
pause after every control message);
o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
delay after resetting its port);
+   p = USB_QUIRK_NO_SET_FEAT_SUSPEND (Hub can't
+   handle set-port-feature-suspend request
+   correctly);
Example: quirks=0781:5580:bk,0a5c:5834:gij
 
usbhid.mousepoll=
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 7f71218cc1e5..a73e3931aecd 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3328,9 +3328,13 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
 * Therefore we will turn on the suspend feature if udev or any of its
 * descendants is enabled for remote wakeup.
 */
-   else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
-   status = set_port_feature(hub->hdev, port1,
-   USB_PORT_FEAT_SUSPEND);
+   else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0) 
{
+   if (hub->hdev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
+   status = -EIO;
+   else
+   status = set_port_feature(hub->hdev, port1,
+   USB_PORT_FEAT_SUSPEND);
+   }
else {
really_suspend = false;
status = 0;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 76ac5d6555ae..9f373579bf9e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -138,6 +138,9 @@ static int quirks_param_set(const char *value, const struct 
kernel_param *kp)
case 'o':
flags |= USB_QUIRK_HUB_SLOW_RESET;
break;
+   case 'p':
+   flags |= USB_QUIRK_NO_SET_FEAT_SUSPEND;
+   break;
/* Ign

Re: [PATCH] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Wed, Apr 14, 2021 at 10:32 PM Alan Stern  wrote:
>
> On Wed, Apr 14, 2021 at 01:07:43PM +0800, Chris Chiu wrote:
> > Thanks for the instructions. I can hit the same timeout problem with
> > runtime PM. The
> > fail rate seems the same as normal PM. (around 1/4 ~ 1/7)
> > root@:/sys/bus/usb/devices/3-4.3# echo auto > power/control
> > root@:/sys/bus/usb/devices/3-4.3# echo on > power/control
> > root@:/sys/bus/usb/devices/3-4.3# dmesg -c
> > [ 2789.679807] usb 3-4: kworker/7:0 timed out on ep0out len=0/0
> > [ 2789.679812] usb 3-4-port3: can't suspend, status -110
> > [ 2789.680078] usb 3-4.3: Failed to suspend device, error -110
>
> Since these are random failures, occurring at a low rate, maybe it would
> help simply to retry the transfer that timed out.  Have you tested this?
>

The problem is the port seems to be dead (at least unresponsive) after
USB_PORT_FEAT_SUSPEND. If I turned on the xhci_hcd debug message,
I'll see lots of retries of the control URB as follows which never get acked
in failure cases.
[  126.616105] xhci_hcd :04:00.3: ep 0x81 - asked for 2 bytes, 1
bytes untransferred

I tried to increase the timeout from 1 second to 2 second and also tried
set USB_PORT_FEAT_SUSPEND again after timeout, but still get timeout.
That also explains why hub_ext_port_status returns -71 (EPROTO from xhci)
in hub_activate() during resuming since the port is in an unknown state.

> > > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > > > > > index 7f71218cc1e5..8478d49bba77 100644
> > > > > > --- a/drivers/usb/core/hub.c
> > > > > > +++ b/drivers/usb/core/hub.c
> > > > > > @@ -3329,8 +3329,11 @@ int usb_port_suspend(struct usb_device 
> > > > > > *udev, pm_message_t msg)
> > > > > >* descendants is enabled for remote wakeup.
> > > > > >*/
> > > > > >   else if (PMSG_IS_AUTO(msg) || 
> > > > > > usb_wakeup_enabled_descendants(udev) > 0)
> > > > > > - status = set_port_feature(hub->hdev, port1,
> > > > > > - USB_PORT_FEAT_SUSPEND);
> > > > > > + if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
> > > > >
> > > > > You should test hub->hdev->quirks, here, not udev->quirks.  The quirk
> > > > > belongs to the Realtek hub, not to the device that's plugged into the
> > > > > hub.
> > > > >
> > > >
> > > > Thanks for pointing that out. I'll verify again and propose a V2 after
> > > > it's done.
> > >
> > > Another thing to consider: You shouldn't return 0 from usb_port_suspend
> > > if the port wasn't actually suspended.  We don't want to kernel to have
> > > a false idea of the hardware's current state.
> > >
> > So we still need the "really_suspend=false". What if I replace it with
> > the following?
> > It's a little verbose but expressive enough. Any suggestions?
> >
> > +   else if (!(hub->hdev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND) &&
> > +   (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) 
> > > 0))
> > +   status = set_port_feature(hub->hdev, port1,
> > +   USB_PORT_FEAT_SUSPEND);
> > else {
> > really_suspend = false;
> > status = 0;
>
> You should do something more like this:
>
> -   else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 
> 0)
> -   status = set_port_feature(hub->hdev, port1,
> -   USB_PORT_FEAT_SUSPEND);
> -   else {
> +   else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 
> 0) {
> +   if (hub->hdev->quirks & USB_QUIRK_NO_SUSPEND)
> +   status = -EIO;
> +   else
> +   status = set_port_feature(hub->hdev, port1,
> +   USB_PORT_FEAT_SUSPEND);
> +   } else {
> really_suspend = false;
> status = 0;
> }
>
> But I would prefer to find a way to make port suspend actually work,
> instead of giving up on it.
>
> Alan Stern

I tried to do that and also dig into the xhci code to check why the TD
(Transfer Descriptor) of the corresponding control msg URB was not
completed. Unfortunately, I didn't find a reasonable answer. I'll verify
the status -EIO and propose a v3 if everything's fine. Please let me
know if there's anything worth trying. Thanks.

Chris

Re: [PATCH] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Tue, Apr 13, 2021 at 10:44 PM Alan Stern  wrote:
>
> On Tue, Apr 13, 2021 at 03:52:14PM +0800, Chris Chiu wrote:
> > On Mon, Apr 12, 2021 at 11:12 PM Alan Stern  
> > wrote:
> > >
> > > On Mon, Apr 12, 2021 at 11:00:06PM +0800, chris.c...@canonical.com wrote:
> > > > The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> > > > "global suspend" in USB 2.0 spec. It's only for many hub devices
> > > > which don't relay wakeup requests from the devices connected to
> > > > downstream ports. For this realtek hub, there's no problem waking
> > > > up the system from connected keyboard.
> > >
> > > What about runtime suspend?  That _does_ require USB_PORT_FEAT_SUSPEND.
> >
> > It's hard to reproduce the same thing with runtime PM. I also don't
> > know the aggressive
> > way to trigger runtime suspend. So I'm assuming the same thing will happen 
> > in
> > runtime PM case because they both go the same usb_port_resume path. Could
> > you please suggest a better way to verify this for runtime PM?
>
> To put a USB device into runtime suspend, do this:
>
> echo 0 >/sys/bus/usb/devices/.../bConfigurationValue
> echo auto >/sys/bus/usb/devices/.../power/control
>
> where ... is the pathname for the device you want to suspend.  (Note
> that this will unbind the device from its driver, so make sure there's
> no possibility of data loss before you do it.)
>
> To resume the device, write "on" to the power/control file.  You can
> verify the runtime-PM status by reading the files in the power/
> subdirectory.
>
Thanks for the instructions. I can hit the same timeout problem with
runtime PM. The
fail rate seems the same as normal PM. (around 1/4 ~ 1/7)
root@:/sys/bus/usb/devices/3-4.3# echo auto > power/control
root@:/sys/bus/usb/devices/3-4.3# echo on > power/control
root@:/sys/bus/usb/devices/3-4.3# dmesg -c
[ 2789.679807] usb 3-4: kworker/7:0 timed out on ep0out len=0/0
[ 2789.679812] usb 3-4-port3: can't suspend, status -110
[ 2789.680078] usb 3-4.3: Failed to suspend device, error -110


> > > > This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.
> > > >
> > > > Signed-off-by: Chris Chiu 
> > > > ---
> > >
> > >
> > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > > > index 7f71218cc1e5..8478d49bba77 100644
> > > > --- a/drivers/usb/core/hub.c
> > > > +++ b/drivers/usb/core/hub.c
> > > > @@ -3329,8 +3329,11 @@ int usb_port_suspend(struct usb_device *udev, 
> > > > pm_message_t msg)
> > > >* descendants is enabled for remote wakeup.
> > > >*/
> > > >   else if (PMSG_IS_AUTO(msg) || 
> > > > usb_wakeup_enabled_descendants(udev) > 0)
> > > > - status = set_port_feature(hub->hdev, port1,
> > > > - USB_PORT_FEAT_SUSPEND);
> > > > + if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
> > >
> > > You should test hub->hdev->quirks, here, not udev->quirks.  The quirk
> > > belongs to the Realtek hub, not to the device that's plugged into the
> > > hub.
> > >
> >
> > Thanks for pointing that out. I'll verify again and propose a V2 after
> > it's done.
>
> Another thing to consider: You shouldn't return 0 from usb_port_suspend
> if the port wasn't actually suspended.  We don't want to kernel to have
> a false idea of the hardware's current state.
>
So we still need the "really_suspend=false". What if I replace it with
the following?
It's a little verbose but expressive enough. Any suggestions?

+   else if (!(hub->hdev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND) &&
+   (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0))
+   status = set_port_feature(hub->hdev, port1,
+   USB_PORT_FEAT_SUSPEND);
else {
really_suspend = false;
status = 0;

Chris

> Alan Stern

[PATCH v2] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[chris . chiu]

From: Chris Chiu 

Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=5487 Rev= 1.47
S:  Manufacturer=Dell Inc.
S:  Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on
the suspend feature of the hub. The usb_resume_device will not be
invoked since the device state is not set to suspended, then the
hub fails to activate subsequently.

The USB_PORT_FEAT_SUSPEND is not really necessary due to the
"global suspend" in USB 2.0 spec. It's only for many hub devices
which don't relay wakeup requests from the devices connected to
downstream ports. For this realtek hub, there's no problem waking
up the system from connected keyboard.

This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.

Signed-off-by: Chris Chiu 
---

Changelog:
  v2: 
Since the 0bda:5413 is the hub device connects to upstream hub
0bda:5487, the upstream hub which fails the USB_PORT_FEAT_SUSPEND
is the target this patch really wants to quirk.
- Fix the quirk target from the connected hub device to the
  upstream hub
- Correct the usb info of the target hub in the commit message
- Revise the description of the quirk

 Documentation/admin-guide/kernel-parameters.txt | 3 +++
 drivers/usb/core/hub.c  | 7 +--
 drivers/usb/core/quirks.c   | 5 +
 include/linux/usb/quirks.h  | 3 +++
 4 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..1bb22a9ea5ba 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5682,6 +5682,9 @@
pause after every control message);
o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
delay after resetting its port);
+   p = USB_QUIRK_NO_SET_FEAT_SUSPEND (Hub can't
+   handle set-port-feature-suspend request
+   correctly);
Example: quirks=0781:5580:bk,0a5c:5834:gij
 
usbhid.mousepoll=
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 7f71218cc1e5..36b38af46a41 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3329,8 +3329,11 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
 * descendants is enabled for remote wakeup.
 */
else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
-   status = set_port_feature(hub->hdev, port1,
-   USB_PORT_FEAT_SUSPEND);
+   if (hub->hdev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
+   status = 0;
+   else
+   status = set_port_feature(hub->hdev, port1,
+   USB_PORT_FEAT_SUSPEND);
else {
really_suspend = false;
status = 0;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 76ac5d6555ae..9f373579bf9e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -138,6 +138,9 @@ static int quirks_param_set(const char *value, const struct 
kernel_param *kp)
case 'o':
flags |= USB_QUIRK_HUB_SLOW_RESET;
break;
+   case 'p':
+   flags |= USB_QUIRK_NO_SET_FEAT_SUSPEND;
+   break;
/* Ignore unrecognized flag characters */
}
}
@@ -406,6 +409,8 @@ static const struct usb_device_id usb_quirk_list[] = {
 
/* Realtek hub in Dell WD19 (Type-C) */
{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+   { USB_DEVICE(0x0bda, 0x5487), .driver_info =
+   USB_QUIRK_NO_SET_FEAT_SUSPEND },
 
/* Generic RTL8153 based ethernet adapters */
{ USB_DEVICE(

Re: [PATCH] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[Chris Chiu]

On Mon, Apr 12, 2021 at 11:12 PM Alan Stern  wrote:
>
> On Mon, Apr 12, 2021 at 11:00:06PM +0800, chris.c...@canonical.com wrote:
> > From: Chris Chiu 
> >
> > Realtek Hub (0bda:5413) in Dell Dock WD19 sometimes fails to work
> > after the system resumes from suspend with remote wakeup enabled
> > device connected:
> > [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> > [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
> > [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
> > [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
> >
> > Information of this hub:
> > T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  9 Spd=480  MxCh= 6
> > D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
> > P:  Vendor=0bda ProdID=5413 Rev= 1.21
> > S:  Manufacturer=Dell Inc.
> > S:  Product=Dell dock
> > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=  0mA
> > I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> > I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> >
> > The failure results from the ETIMEDOUT by chance when turning on
> > the suspend feature of the hub. The usb_resume_device will not be
> > invoked since the device state is not set to suspended, then the
> > hub fails to activate subsequently.
> >
> > The USB_PORT_FEAT_SUSPEND is not really necessary due to the
> > "global suspend" in USB 2.0 spec. It's only for many hub devices
> > which don't relay wakeup requests from the devices connected to
> > downstream ports. For this realtek hub, there's no problem waking
> > up the system from connected keyboard.
>
> What about runtime suspend?  That _does_ require USB_PORT_FEAT_SUSPEND.

It's hard to reproduce the same thing with runtime PM. I also don't
know the aggressive
way to trigger runtime suspend. So I'm assuming the same thing will happen in
runtime PM case because they both go the same usb_port_resume path. Could
you please suggest a better way to verify this for runtime PM?

>
> > This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.
> >
> > Signed-off-by: Chris Chiu 
> > ---
>
>
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 7f71218cc1e5..8478d49bba77 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -3329,8 +3329,11 @@ int usb_port_suspend(struct usb_device *udev, 
> > pm_message_t msg)
> >* descendants is enabled for remote wakeup.
> >*/
> >   else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 
> > 0)
> > - status = set_port_feature(hub->hdev, port1,
> > - USB_PORT_FEAT_SUSPEND);
> > + if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
>
> You should test hub->hdev->quirks, here, not udev->quirks.  The quirk
> belongs to the Realtek hub, not to the device that's plugged into the
> hub.
>

Thanks for pointing that out. I'll verify again and propose a V2 after
it's done.

> Alan Stern

[PATCH] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub

[chris . chiu]

From: Chris Chiu 

Realtek Hub (0bda:5413) in Dell Dock WD19 sometimes fails to work
after the system resumes from suspend with remote wakeup enabled
device connected:
[ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
[ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
[ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)

Information of this hub:
T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  9 Spd=480  MxCh= 6
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
P:  Vendor=0bda ProdID=5413 Rev= 1.21
S:  Manufacturer=Dell Inc.
S:  Product=Dell dock
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms

The failure results from the ETIMEDOUT by chance when turning on
the suspend feature of the hub. The usb_resume_device will not be
invoked since the device state is not set to suspended, then the
hub fails to activate subsequently.

The USB_PORT_FEAT_SUSPEND is not really necessary due to the
"global suspend" in USB 2.0 spec. It's only for many hub devices
which don't relay wakeup requests from the devices connected to
downstream ports. For this realtek hub, there's no problem waking
up the system from connected keyboard.

This commit bypasses the USB_PORT_FEAT_SUSPEND for the quirky hub.

Signed-off-by: Chris Chiu 
---
 Documentation/admin-guide/kernel-parameters.txt | 3 +++
 drivers/usb/core/hub.c  | 7 +--
 drivers/usb/core/quirks.c   | 5 +
 include/linux/usb/quirks.h  | 3 +++
 4 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..c14214469ad6 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5682,6 +5682,9 @@
pause after every control message);
o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
delay after resetting its port);
+   p = USB_QUIRK_NO_SET_FEAT_SUSPEND (Device can't
+   handle set port-feature-suspend request
+   correctly);
Example: quirks=0781:5580:bk,0a5c:5834:gij
 
usbhid.mousepoll=
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 7f71218cc1e5..8478d49bba77 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3329,8 +3329,11 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
 * descendants is enabled for remote wakeup.
 */
else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)
-   status = set_port_feature(hub->hdev, port1,
-   USB_PORT_FEAT_SUSPEND);
+   if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND)
+   status = 0;
+   else
+   status = set_port_feature(hub->hdev, port1,
+   USB_PORT_FEAT_SUSPEND);
else {
really_suspend = false;
status = 0;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 76ac5d6555ae..53689de53900 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -138,6 +138,9 @@ static int quirks_param_set(const char *value, const struct 
kernel_param *kp)
case 'o':
flags |= USB_QUIRK_HUB_SLOW_RESET;
break;
+   case 'p':
+   flags |= USB_QUIRK_NO_SET_FEAT_SUSPEND;
+   break;
/* Ignore unrecognized flag characters */
}
}
@@ -406,6 +409,8 @@ static const struct usb_device_id usb_quirk_list[] = {
 
/* Realtek hub in Dell WD19 (Type-C) */
{ USB_DEVICE(0x0bda, 0x0487), .driver_info = USB_QUIRK_NO_LPM },
+   { USB_DEVICE(0x0bda, 0x5413), .driver_info =
+   USB_QUIRK_NO_SET_FEAT_SUSPEND },
 
/* Generic RTL8153 based ethernet adapters */
{ USB_DEVICE(0x0bda, 0x8153), .driver_info = USB_QUIRK_NO_LPM },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 5e4c497f54d6..3b8930b99554 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -72,4 +72,7 @@
 /* device has endpoints that should be ignored */
 #define USB_QUIRK_ENDPOINT_IGNORE  BIT(15)
 
+/* Device can't handle set port-feature-suspend req

[PATCH] mailmap: update the email address for Chris Chiu

[chris . chiu]

From: Chris Chiu 

Redirect my older email addresses in the git logs.

Signed-off-by: Chris Chiu 
---
 .mailmap | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index 85b93cdefc87..1f8579db5a3f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -65,6 +65,8 @@ Changbin Du  
 Changbin Du  
 Chao Yu  
 Chao Yu  
+Chris Chiu  
+Chris Chiu  
 Christophe Ricard 
 Christoph Hellwig 
 Corey Minyard 
-- 
2.20.1

[PATCH] block: clear GD_NEED_PART_SCAN later in bdev_disk_changed

[chris . chiu]

From: Chris Chiu 

The GD_NEED_PART_SCAN is set by bdev_check_media_change to initiate
a partition scan while removing a block device. It should be cleared
after blk_drop_paritions because blk_drop_paritions could return
-EBUSY and then the consequence __blkdev_get has no chance to do
delete_partition if GD_NEED_PART_SCAN already cleared.

It causes some problems on some card readers. Ex. Realtek card
reader 0bda:0328 and 0bda:0158. The device node of the partition
will not disappear after the memory card removed. Thus the user
applications can not update the device mapping correctly.

BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920874
Signed-off-by: Chris Chiu 
---
 fs/block_dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 92ed7d5df677..28d583fcdc2c 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1240,13 +1240,13 @@ int bdev_disk_changed(struct block_device *bdev, bool 
invalidate)
 
lockdep_assert_held(>bd_mutex);
 
-   clear_bit(GD_NEED_PART_SCAN, >bd_disk->state);
-
 rescan:
ret = blk_drop_partitions(bdev);
if (ret)
return ret;
 
+   clear_bit(GD_NEED_PART_SCAN, >state);
+
/*
 * Historically we only set the capacity to zero for devices that
 * support partitions (independ of actually having partitions created).
-- 
2.20.1

[PATCH] ACPI: video: Add missing callback back for Sony VPCEH3U1E

[chris . chiu]

From: Chris Chiu 

The .callback of the quirk for Sony VPCEH3U1E was unintetionally
removed by the commit 25417185e9b5 ("ACPI: video: Add DMI quirk
for GIGABYTE GB-BXBT-2807"). Add it back to make sure the quirk
for Sony VPCEH3U1E works as expected.

Signed-off-by: Chris Chiu 
Reported-by: Pavel Machek 
---
 drivers/acpi/video_detect.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 811d298637cb..83cd4c95faf0 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -147,6 +147,7 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
},
{
+   .callback = video_detect_force_vendor,
.ident = "Sony VPCEH3U1E",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
-- 
2.20.1

Re: No sound cards detected on Kabylake laptops after upgrade to kernel 5.8

[Chris Chiu]

On Tue, Mar 9, 2021 at 11:29 PM Cezary Rojewski
 wrote:
>
> On 2021-03-09 1:19 PM, Chris Chiu wrote:
> > Hi Guys,
> >  We have received reports that on some Kabylake laptops (Acer Swift
> > SF314-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
> > detected after upgrade to kernel later than 5.8. These laptops have
> > one thing in common, all of them have Realtek audio codec and connect
> > the internal microphone to DMIC of the Intel SST controller either
> > [8086:9d71] or [8086:9dc8]. Please refer to
> > https://bugzilla.kernel.org/show_bug.cgi?id=201251#c246 and
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1915117.
> >
> >  From the dmesg from kernel 5.8, the sound related parts only show
> > as follows but the expected snd_hda_codec_realtek and the snd_soc_skl
> > are not even loaded then.
> > [ 13.357495] snd_hda_intel :00:1f.3: DSP detected with PCI
> > class/subclass/prog-if info 0x040100
> > [ 13.357500] snd_hda_intel :00:1f.3: Digital mics found on
> > Skylake+ platform, using SST driver
> >
> >  Building the kernel with the CONFIG_SND_SOC_INTEL_KBL removed can
> > load the snd_hda_codec_realtek successfully and the pulseaudio and
> > alsa-utils can detect the sound cards again. The result of bisecting
> > between kernel 5.4 and 5.8 also get similar result, reverting the
> > commit "ALSA: hda: Allow SST driver on SKL and KBL platforms with
> > DMIC" can fix the issue. I tried to generate the required firmware for
> > snd_soc_skl but it did not help. Please refer to what I did in
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1915117/comments/14
> > and 
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1915117/comments/18.
> >
> >  Since the skl_hda_dsp_generic-tplg.bin and dfw_sst.bin are not in
> > the linux-firmware. The Intel SST support for Skylake family is not
> > yet complete. Can we simply revert the "ALSA: hda: Allow SST driver on
> > SKL and KBL platforms with DMIC" in the current stage and wait for SOF
> > support for Skylake family? Or please suggest a better solution for
> > this. Thanks
> >
> > Chris
> >
>
> Hello Chris,
>
> Guide: "Linux: HDA+DMIC with skylake driver" [1] should help
> understanding history behind the problem as well as fixing it.
>
> Upstream skylake driver - snd_soc_skl - is intended to support HDA DSP +
> DMIC configuration via means of snd_soc_skl_hda_dsp machine board
> driver. You _may_ switch to legacy HDAudio driver - snd_hda_intel -
> losing DMIC support in the process. To remove any confusion - for
> Skylake and Kabylake platforms, snd_soc_skl is your option.
>
> Now, due to above, I doubt any skylake-related topology has ever been
> upstreamed to linux-firmware as a) most boards are I2S-based, these are
> used by our clients which we support via separate channel b) hda
> dsp+dmic support on linux for missing until early 2020.
>
> Topologies for most common skylake driver configurations:
> - skl/kbl with i2s rt286
> - apl/glk with i2s rt298
> -  with hda dsp
> can be found in alsa-topology-conf [2].
>
> Standard, official tool called 'alsatplg' is capable of compiling these
> into binary form which, after being transferred to /lib/firmware/ may be
> consumed by the driver during runtime.
> I have no problem with providing precompiled binaries to linux-firmware,
> if that's what community wants.
>
> Regards,
> Czarek
>
>

I think the guild [1] is too complicated for normal users to fix the problem.
Given it's not only the internal microphone being affected, it's no sound
devices being created at all so no audio functions can work after kernel 5.8.

Is there any potential problem to built-in the " with hda dsp" precompiled
binary in linux-firmware?

Chris

> [1]: https://gist.github.com/crojewsk/4e6382bfb0dbfaaf60513174211f29cb
> [2]: https://github.com/alsa-project/alsa-topology-conf/tree/master/topology

No sound cards detected on Kabylake laptops after upgrade to kernel 5.8

[Chris Chiu]

Hi Guys,
We have received reports that on some Kabylake laptops (Acer Swift
SF314-54/55 and Lenovo Yoga C930...etc), all sound cards no longer be
detected after upgrade to kernel later than 5.8. These laptops have
one thing in common, all of them have Realtek audio codec and connect
the internal microphone to DMIC of the Intel SST controller either
[8086:9d71] or [8086:9dc8]. Please refer to
https://bugzilla.kernel.org/show_bug.cgi?id=201251#c246 and
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1915117.

From the dmesg from kernel 5.8, the sound related parts only show
as follows but the expected snd_hda_codec_realtek and the snd_soc_skl
are not even loaded then.
[ 13.357495] snd_hda_intel :00:1f.3: DSP detected with PCI
class/subclass/prog-if info 0x040100
[ 13.357500] snd_hda_intel :00:1f.3: Digital mics found on
Skylake+ platform, using SST driver

Building the kernel with the CONFIG_SND_SOC_INTEL_KBL removed can
load the snd_hda_codec_realtek successfully and the pulseaudio and
alsa-utils can detect the sound cards again. The result of bisecting
between kernel 5.4 and 5.8 also get similar result, reverting the
commit "ALSA: hda: Allow SST driver on SKL and KBL platforms with
DMIC" can fix the issue. I tried to generate the required firmware for
snd_soc_skl but it did not help. Please refer to what I did in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1915117/comments/14
and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1915117/comments/18.

Since the skl_hda_dsp_generic-tplg.bin and dfw_sst.bin are not in
the linux-firmware. The Intel SST support for Skylake family is not
yet complete. Can we simply revert the "ALSA: hda: Allow SST driver on
SKL and KBL platforms with DMIC" in the current stage and wait for SOF
support for Skylake family? Or please suggest a better solution for
this. Thanks

Chris

Re: [PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256

[Chris Chiu]

On Fri, Feb 26, 2021 at 10:06 AM Jian-Hong Pan  wrote:
>
>  於 2021年2月26日 週五 上午9:04寫道：
> >
> > From: Chris Chiu 
> >
> > The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
> > both the headset mic and the internal mic. Introduce new fixup
> > to enable the jack sense and the headset mic. However, the internal
> > mic actually connects to Intel SST audio. It still needs Intel SST
> > support to make internal mic capture work.
> >
> > Signed-off-by: Chris Chiu 
> > ---
> >   v1 -> v2: remove unnecessary aamix fixup
> >
> >  sound/pci/hda/patch_realtek.c | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 1927605f0f7e..4871507cd4bf 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -6406,6 +6406,7 @@ enum {
> > ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
> > ALC282_FIXUP_ACER_DISABLE_LINEOUT,
> > ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
> > +   ALC256_FIXUP_ACER_HEADSET_MIC,
> >  };
> >
> >  static const struct hda_fixup alc269_fixups[] = {
> > @@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
> > },
> > +   [ALC256_FIXUP_ACER_HEADSET_MIC] = {
> > +   .type = HDA_FIXUP_PINS,
> > +   .v.pins = (const struct hda_pintbl[]) {
> > +   { 0x19, 0x02a1113c }, /* use as headset mic, 
> > without its own jack detect */
> > +   { 0x1a, 0x90a1092f }, /* use as internal mic */
>
> Since NID 0x1a is an internal DMIC, should this connection type be 0h?
> Or, even the quirk of the internal DMIC is not needed for this case.
> Because, it is Intel SST DMIC that does not connect to Realtek HDA
> CODEC.  (Not sure for this one)
>
> The quirk of NID 0x19 is okay for me.
>
Actually I tried the existing ALC256_FIXUP_ACER_MIC_NO_PRESENT
which only quirk the 0x19, the jack sense works but the headset mic
is still absent. That's the reason why I still need the 0x1a as the internal
mic. I've verified the headset mic can be detected and work w/o problem.

Chris

> BR,
> Jian-Hong Pan
>
> > +   { }
> > +   },
> > +   .chained = true,
> > +   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > +   },
> >  };
> >
> >  static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] 
> > = {
> > SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500", 
> > ALC299_FIXUP_PREDATOR_SPK),
> > SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox", 
> > ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
> > SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G", 
> > ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
> > +   SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54", 
> > ALC256_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", 
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", 
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", 
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > +   SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55", 
> > ALC256_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", 
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", 
> > ALC233_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", 
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > --
> > 2.20.1
> >

[PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256

[chris . chiu]

From: Chris Chiu 

The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
both the headset mic and the internal mic. Introduce new fixup
to enable the jack sense and the headset mic. However, the internal
mic actually connects to Intel SST audio. It still needs Intel SST
support to make internal mic capture work.

Signed-off-by: Chris Chiu 
---
  v1 -> v2: remove unnecessary aamix fixup

 sound/pci/hda/patch_realtek.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1927605f0f7e..4871507cd4bf 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6406,6 +6406,7 @@ enum {
ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
+   ALC256_FIXUP_ACER_HEADSET_MIC,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
},
+   [ALC256_FIXUP_ACER_HEADSET_MIC] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x19, 0x02a1113c }, /* use as headset mic, without 
its own jack detect */
+   { 0x1a, 0x90a1092f }, /* use as internal mic */
+   { }
+   },
+   .chained = true,
+   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500", 
ALC299_FIXUP_PREDATOR_SPK),
SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox", 
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G", 
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54", 
ALC256_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+   SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55", 
ALC256_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", 
ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", 
ALC255_FIXUP_ACER_HEADSET_MIC),
-- 
2.20.1

[PATCH v2] ALSA: hda/realtek: Enable headset mic of Acer SWIFT with ALC256

[chris . chiu]

From: Chris Chiu 

The Acer SWIFT Swift SF314-54/55 laptops with ALC256 cannot detect
both the headset mic and the internal mic. Introduce new fixup
to enable the jack sense and the headset mic. However, the internal
mic actually connects to Intel SST audio. It still needs Intel SST
support to make internal mic capture work.

Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1927605f0f7e..4871507cd4bf 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6406,6 +6406,7 @@ enum {
ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
+   ALC256_FIXUP_ACER_HEADSET_MIC,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7853,6 +7854,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
},
+   [ALC256_FIXUP_ACER_HEADSET_MIC] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x19, 0x02a1113c }, /* use as headset mic, without 
its own jack detect */
+   { 0x1a, 0x90a1092f }, /* use as internal mic */
+   { }
+   },
+   .chained = true,
+   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7879,9 +7890,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500", 
ALC299_FIXUP_PREDATOR_SPK),
SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox", 
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G", 
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54", 
ALC256_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+   SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55", 
ALC256_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890", 
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21", 
ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T", 
ALC255_FIXUP_ACER_HEADSET_MIC),
-- 
2.20.1

Re: [PATCH] ALSA: hda/realtek: Enable MICs of Acer SWIFT with ALC256

[Chris Chiu]

On Thu, Feb 25, 2021 at 5:32 PM Takashi Iwai  wrote:
>
> On Thu, 25 Feb 2021 10:21:07 +0100,
> Chris Chiu wrote:
> >
> > The Acer SWIFT Swift SF314-54/55 with ALC256 cannot detect the headset
> > microphone and suffers the noise problem in audio capture.
> >
> > This patch enables the headset jack sense and fixes the noise problem with
> > aamix fixup.
> >
> > Signed-off-by: Chris Chiu 
>
> The patch seems broken due to the line break and cannot be applied
> cleanly.  Could you resubmit?
>
Talked to Jian-Hong who was working on SF314-55, the aamix disable
does not really make difference. And we don't have to quirk  0x1a since
the internal mic connects to intel SST audio. I'll make a V2 patch and
resubmit. Thanks.

>
> thanks,
>
> Takashi
>
>
> > ---
> >  sound/pci/hda/patch_realtek.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index 290645516313..57e4dbcd76a9 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -6372,6 +6372,8 @@ enum {
> > ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
> > ALC282_FIXUP_ACER_DISABLE_LINEOUT,
> > ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
> > +   ALC256_FIXUP_ACER_SWIFT_NO_MIC_PRESENCE,
> > +   ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX,
> >  };
> >
> >  static const struct hda_fixup alc269_fixups[] = {
> > @@ -7815,6 +7817,22 @@ static const struct hda_fixup alc269_fixups[] = {
> > .chained = true,
> > .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
> > },
> > +   [ALC256_FIXUP_ACER_SWIFT_NO_MIC_PRESENCE] = {
> > +   .type = HDA_FIXUP_PINS,
> > +   .v.pins = (const struct hda_pintbl[]) {
> > +   { 0x19, 0x02a1113c }, /* use as headset mic,
> > without its own jack detect */
> > +   { 0x1a, 0x90a1092f }, /* use as internal mic */
> > +   { },
> > +   },
> > +   .chained = true,
> > +   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > +   },
> > +   [ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX] = {
> > +   .type = HDA_FIXUP_FUNC,
> > +   .v.func = alc_fixup_disable_aamix,
> > +   .chained = true,
> > +   .chain_id = ALC256_FIXUP_ACER_SWIFT_NO_MIC_PRESENCE
> > +   },
> >  };
> >
> >  static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -7841,9 +7859,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] 
> > = {
> > SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
> > ALC299_FIXUP_PREDATOR_SPK),
> > SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
> > ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
> > SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
> > ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
> > +   SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54",
> > ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX),
> > SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > +   SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55",
> > ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX),
> > SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
> > ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
> > ALC233_FIXUP_ACER_HEADSET_MIC),
> > SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
> > ALC255_FIXUP_ACER_HEADSET_MIC),
> > --
> > 2.20.1
> >

[PATCH] ALSA: hda/realtek: Enable MICs of Acer SWIFT with ALC256

[Chris Chiu]

The Acer SWIFT Swift SF314-54/55 with ALC256 cannot detect the headset
microphone and suffers the noise problem in audio capture.

This patch enables the headset jack sense and fixes the noise problem with
aamix fixup.

Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 290645516313..57e4dbcd76a9 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6372,6 +6372,8 @@ enum {
ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
+   ALC256_FIXUP_ACER_SWIFT_NO_MIC_PRESENCE,
+   ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX,
 };

 static const struct hda_fixup alc269_fixups[] = {
@@ -7815,6 +7817,22 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
},
+   [ALC256_FIXUP_ACER_SWIFT_NO_MIC_PRESENCE] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x19, 0x02a1113c }, /* use as headset mic,
without its own jack detect */
+   { 0x1a, 0x90a1092f }, /* use as internal mic */
+   { },
+   },
+   .chained = true,
+   .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
+   },
+   [ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = alc_fixup_disable_aamix,
+   .chained = true,
+   .chain_id = ALC256_FIXUP_ACER_SWIFT_NO_MIC_PRESENCE
+   },
 };

 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7841,9 +7859,11 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500",
ALC299_FIXUP_PREDATOR_SPK),
SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox",
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G",
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1025, 0x1269, "Acer SWIFT SF314-54",
ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX),
SND_PCI_QUIRK(0x1025, 0x128f, "Acer Veriton Z6860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1290, "Acer Veriton Z4860G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1291, "Acer Veriton Z4660G",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
+   SND_PCI_QUIRK(0x1025, 0x129c, "Acer SWIFT SF314-55",
ALC256_FIXUP_ACER_SWIFT_DISABLE_AAMIX),
SND_PCI_QUIRK(0x1025, 0x1308, "Acer Aspire Z24-890",
ALC286_FIXUP_ACER_AIO_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x132a, "Acer TravelMate B114-21",
ALC233_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1330, "Acer TravelMate X514-51T",
ALC255_FIXUP_ACER_HEADSET_MIC),
--
2.20.1

[PATCH] ALSA: hda/realtek - Limit int mic boost on Acer Aspire E5-575T

[Chris Chiu]

The Acer Apire E5-575T laptop with codec ALC255 has a terrible
background noise comes from internal mic capture. And the jack
sensing dose not work for headset like some other Acer laptops.

This patch limits the internal mic boost on top of the existing
ALC255_FIXUP_ACER_MIC_NO_PRESENCE quirk for Acer Aspire E5-575T.

Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3c1d2a3fb1a4..60eb8383a704 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6371,6 +6371,7 @@ enum {
ALC256_FIXUP_HP_HEADSET_MIC,
ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
+   ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7808,6 +7809,12 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+   [ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST] = {
+   .type = HDA_FIXUP_FUNC,
+   .v.func = alc269_fixup_limit_int_mic_boost,
+   .chained = true,
+   .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7826,6 +7833,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820", 
ALC269VC_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", 
ALC283_FIXUP_CHROME_BOOK),
+   SND_PCI_QUIRK(0x1025, 0x1094, "Acer Aspire E5-575T", 
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST),
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G", 
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432", 
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1166, "Acer Veriton N4640G", 
ALC269_FIXUP_LIFEBOOK),
-- 
2.20.1

[PATCH v3 1/4] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

[Chris Chiu]

On at least one laptop (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. The GPIO related
information should be mapped to the rt5645 driver to enable the jack
detection also on non-DT platforms.

Signed-off-by: Chris Chiu 
---
  v2 -> v3:
- restore the terminator {} of the dmi_platform_data[]
  v1 -> v2:
- none

 sound/soc/codecs/rt5645.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 420003d062c7..af8f95644f11 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -42,6 +42,8 @@ static unsigned int quirk = -1;
 module_param(quirk, uint, 0444);
 MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
+static const struct acpi_gpio_mapping *cht_rt5645_gpios;
+
 #define RT5645_DEVICE_ID 0x6308
 #define RT5650_DEVICE_ID 0x6419
 
@@ -3848,6 +3850,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
}
 
+   if (cht_rt5645_gpios && has_acpi_companion(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->gpiod_hp_det = devm_gpiod_get_optional(>dev, "hp-detect",
   GPIOD_IN);
 
-- 
2.20.1

[PATCH v3 3/4] ASoC: rt5645: add inv_hp_det flag

[Chris Chiu]

The ECS EF20EA laptop use gpio for jack detection instead of rt5645
rt5645 JD. However, the GPIO polarity is inverse for hp-detect based
on the _DSD property of the RTK2 device.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"hp-detect-gpio", Package() {^RTK2, 0, 0, 1 }},
}
})

This flag will invert the hp-detect gpio polarity.

Signed-off-by: Chris Chiu 
---
  v2 -> v3:
- none
  v1 -> v2:
- none

 include/sound/rt5645.h| 2 ++
 sound/soc/codecs/rt5645.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/include/sound/rt5645.h b/include/sound/rt5645.h
index 39a77c7cea36..710c95be5509 100644
--- a/include/sound/rt5645.h
+++ b/include/sound/rt5645.h
@@ -22,6 +22,8 @@ struct rt5645_platform_data {
bool level_trigger_irq;
/* Invert JD1_1 status polarity */
bool inv_jd1_1;
+   /* Invert HP detect status polarity */
+   bool inv_hp_pol;
 
/* Value to asign to snd_soc_card.long_name */
const char *long_name;
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 770801de42a6..4fd91ee3cfaa 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -34,6 +34,7 @@
 #define QUIRK_INV_JD1_1(q) ((q) & 1)
 #define QUIRK_LEVEL_IRQ(q) (((q) >> 1) & 1)
 #define QUIRK_IN2_DIFF(q)  (((q) >> 2) & 1)
+#define QUIRK_INV_HP_POL(q)(((q) >> 3) & 1)
 #define QUIRK_JD_MODE(q)   (((q) >> 4) & 7)
 #define QUIRK_DMIC1_DATA_PIN(q)(((q) >> 8) & 3)
 #define QUIRK_DMIC2_DATA_PIN(q)(((q) >> 12) & 3)
@@ -3263,6 +3264,8 @@ static void rt5645_jack_detect_work(struct work_struct 
*work)
case 0: /* Not using rt5645 JD */
if (rt5645->gpiod_hp_det) {
gpio_state = gpiod_get_value(rt5645->gpiod_hp_det);
+   if (rt5645->pdata.inv_hp_pol)
+   gpio_state ^= 1;
dev_dbg(rt5645->component->dev, "gpio_state = %d\n",
gpio_state);
report = rt5645_jack_detect(rt5645->component, 
gpio_state);
@@ -3872,6 +3875,7 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.in2_diff = QUIRK_IN2_DIFF(quirk);
rt5645->pdata.level_trigger_irq = QUIRK_LEVEL_IRQ(quirk);
rt5645->pdata.inv_jd1_1 = QUIRK_INV_JD1_1(quirk);
+   rt5645->pdata.inv_hp_pol = QUIRK_INV_HP_POL(quirk);
rt5645->pdata.jd_mode = QUIRK_JD_MODE(quirk);
rt5645->pdata.dmic1_data_pin = QUIRK_DMIC1_DATA_PIN(quirk);
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
-- 
2.20.1

[PATCH v3 2/4] ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series

[Chris Chiu]

Add the hp-detect gpio for ECS EF20 series laptops based on the
_CRS defined in DSDT table.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Signed-off-by: Chris Chiu 
---
  v2 -> v3:
- restore the terminator {} of the dmi_platform_data[]
  v1 -> v2:
- Invoke callback() of the DMI quirk if it exists.

 sound/soc/codecs/rt5645.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index af8f95644f11..770801de42a6 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3653,6 +3653,19 @@ static const struct rt5645_platform_data 
kahlee_platform_data = {
.jd_mode = 3,
 };
 
+static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
+   { "hp-detect-gpios", _hp_detect, 1 },
+   { },
+};
+
+static int cht_rt5645_ef20_quirk_cb(const struct dmi_system_id *id)
+{
+   cht_rt5645_gpios = cht_rt5645_ef20_gpios;
+   return 1;
+}
+
 static const struct dmi_system_id dmi_platform_data[] = {
{
.ident = "Chrome Buddy",
@@ -3782,6 +3795,20 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)_braswell_platform_data,
},
+   {
+   .ident = "EF20",
+   .callback = cht_rt5645_ef20_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
+   },
+   },
+   {
+   .ident = "EF20EA",
+   .callback = cht_rt5645_ef20_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
{ }
 };
 
-- 
2.20.1

[PATCH v3 4/4] ASoC: rt5645: Enable internal microphone and JD on ECS EF20

[Chris Chiu]

On ECS EF20 series laptops, the internal mic is on DMIC2/IN2P.
And they need the inv_hp_det to make jack detection to work as
exoected.

Signed-off-by: Chris Chiu 
---
  v2 -> v3:
- restore the terminator {} of the dmi_platform_data[]
  v1 -> v2:
- none

 sound/soc/codecs/rt5645.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 4fd91ee3cfaa..3c082c4ac3fc 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3656,6 +3656,12 @@ static const struct rt5645_platform_data 
kahlee_platform_data = {
.jd_mode = 3,
 };
 
+static const struct rt5645_platform_data ecs_ef20_platform_data = {
+   .dmic1_data_pin = RT5645_DMIC1_DISABLE,
+   .dmic2_data_pin = RT5645_DMIC_DATA_IN2P,
+   .inv_hp_pol = 1,
+};
+
 static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
 
 static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
@@ -3804,6 +3810,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
},
+   .driver_data = (void *)_ef20_platform_data,
},
{
.ident = "EF20EA",
@@ -3811,6 +3818,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
},
+   .driver_data = (void *)_ef20_platform_data,
},
{ }
 };
-- 
2.20.1

[PATCH v3 0/4] ASoC: rt5645: Enable internal mic and headset on ECS EF20

[Chris Chiu]

These patches are trying to fix the jack detection and internal
microphone problems on ECS EF20 series laptops which are empowered
by Intel Atom x5-Z8350 CPU (CherryTrail) with Realtek rt5645 audio
codec.

---
  v2 -> v3:
Restore the accidentally removed terminator of the
dmi_platform_data[].

  v1 -> v2:
Invoke callback() of the DMI quirk if it exists, because
the dmi_first_match() doesn't.
---

Chris Chiu (4):
  ASoC: rt5645: Introduce mapping for ACPI-defined GPIO
  ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series
  ASoC: rt5645: add inv_hp_det flag
  ASoC: rt5645: Enable internal microphone and JD on ECS EF20

 include/sound/rt5645.h|  2 ++
 sound/soc/codecs/rt5645.c | 45 +++
 2 files changed, 47 insertions(+)

-- 
2.20.1

Re: [PATCH 1/4] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

[Chris Chiu]

On Thu, Jan 7, 2021 at 10:28 PM Mark Brown  wrote:
>
> On Thu, Jan 07, 2021 at 05:06:22PM +0800, Chris Chiu wrote:
>
> > +static const struct acpi_gpio_mapping *cht_rt5645_gpios;
> > +
>
> You're adding a read only static variable with no way to set it.  This
> doesn't actually do anything?
>
This is a pointer to a 'const 'struct acpi_gpio_mapping', and I will
need it to point to
the 'static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[]' in
my consequent
patch '[PATCH 2/4] ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series'.

I take the same idea from 'sound/soc/intel/boards/bytcr_rt5651.c' line 90.
And it did work as expected on my ECS EF20EA

> > @@ -3780,7 +3782,6 @@ static const struct dmi_system_id dmi_platform_data[] 
> > = {
> >   },
> >   .driver_data = (void *)_braswell_platform_data,
> >   },
> > - { }
> >  };
> >
>
> This is an unrelated change which removes the terminator on the array
> which will cause issues.

Thanks for pointing that out. It's not my intention. I accidentally
removed it. I'll fix this in v3.

Chris

[PATCH v2 4/4] ASoC: rt5645: Enable internal microphone and JD on ECS EF20

[Chris Chiu]

On ECS EF20 series laptops, the internal mic is on DMIC2/IN2P.
And they need the inv_hp_det to make jack detection to work as
exoected.

Signed-off-by: Chris Chiu 
---
  v1 -> v2:
- none

 sound/soc/codecs/rt5645.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index ca1bdb67ecc5..6628b7e5a583 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3656,6 +3656,12 @@ static const struct rt5645_platform_data 
kahlee_platform_data = {
.jd_mode = 3,
 };
 
+static const struct rt5645_platform_data ecs_ef20_platform_data = {
+   .dmic1_data_pin = RT5645_DMIC1_DISABLE,
+   .dmic2_data_pin = RT5645_DMIC_DATA_IN2P,
+   .inv_hp_pol = 1,
+};
+
 static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
 
 static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
@@ -3804,6 +3810,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
},
+   .driver_data = (void *)_ef20_platform_data,
},
{
.ident = "EF20EA",
@@ -3811,6 +3818,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
},
+   .driver_data = (void *)_ef20_platform_data,
},
 };
 
-- 
2.20.1

[PATCH v2 3/4] ASoC: rt5645: add inv_hp_det flag

[Chris Chiu]

The ECS EF20EA laptop use gpio for jack detection instead of rt5645
rt5645 JD. However, the GPIO polarity is inverse for hp-detect based
on the _DSD property of the RTK2 device.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"hp-detect-gpio", Package() {^RTK2, 0, 0, 1 }},
}
})

This flag will invert the hp-detect gpio polarity.

Signed-off-by: Chris Chiu 
---
  v1 -> v2:
- none

 include/sound/rt5645.h| 2 ++
 sound/soc/codecs/rt5645.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/include/sound/rt5645.h b/include/sound/rt5645.h
index 39a77c7cea36..710c95be5509 100644
--- a/include/sound/rt5645.h
+++ b/include/sound/rt5645.h
@@ -22,6 +22,8 @@ struct rt5645_platform_data {
bool level_trigger_irq;
/* Invert JD1_1 status polarity */
bool inv_jd1_1;
+   /* Invert HP detect status polarity */
+   bool inv_hp_pol;
 
/* Value to asign to snd_soc_card.long_name */
const char *long_name;
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 94faa0a9561f..ca1bdb67ecc5 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -34,6 +34,7 @@
 #define QUIRK_INV_JD1_1(q) ((q) & 1)
 #define QUIRK_LEVEL_IRQ(q) (((q) >> 1) & 1)
 #define QUIRK_IN2_DIFF(q)  (((q) >> 2) & 1)
+#define QUIRK_INV_HP_POL(q)(((q) >> 3) & 1)
 #define QUIRK_JD_MODE(q)   (((q) >> 4) & 7)
 #define QUIRK_DMIC1_DATA_PIN(q)(((q) >> 8) & 3)
 #define QUIRK_DMIC2_DATA_PIN(q)(((q) >> 12) & 3)
@@ -3263,6 +3264,8 @@ static void rt5645_jack_detect_work(struct work_struct 
*work)
case 0: /* Not using rt5645 JD */
if (rt5645->gpiod_hp_det) {
gpio_state = gpiod_get_value(rt5645->gpiod_hp_det);
+   if (rt5645->pdata.inv_hp_pol)
+   gpio_state ^= 1;
dev_dbg(rt5645->component->dev, "gpio_state = %d\n",
gpio_state);
report = rt5645_jack_detect(rt5645->component, 
gpio_state);
@@ -3873,6 +3876,7 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.in2_diff = QUIRK_IN2_DIFF(quirk);
rt5645->pdata.level_trigger_irq = QUIRK_LEVEL_IRQ(quirk);
rt5645->pdata.inv_jd1_1 = QUIRK_INV_JD1_1(quirk);
+   rt5645->pdata.inv_hp_pol = QUIRK_INV_HP_POL(quirk);
rt5645->pdata.jd_mode = QUIRK_JD_MODE(quirk);
rt5645->pdata.dmic1_data_pin = QUIRK_DMIC1_DATA_PIN(quirk);
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
-- 
2.20.1

[PATCH v2 2/4] ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series

[Chris Chiu]

Add the hp-detect gpio for ECS EF20 series laptops based on the
_CRS defined in DSDT table.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Signed-off-by: Chris Chiu 
---
  v1 -> v2:
- Invoke callback() of the DMI quirk if it exists.

 sound/soc/codecs/rt5645.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 78f0ab0a008e..94faa0a9561f 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3653,6 +3653,19 @@ static const struct rt5645_platform_data 
kahlee_platform_data = {
.jd_mode = 3,
 };
 
+static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
+   { "hp-detect-gpios", _hp_detect, 1 },
+   { },
+};
+
+static int cht_rt5645_ef20_quirk_cb(const struct dmi_system_id *id)
+{
+   cht_rt5645_gpios = cht_rt5645_ef20_gpios;
+   return 1;
+}
+
 static const struct dmi_system_id dmi_platform_data[] = {
{
.ident = "Chrome Buddy",
@@ -3782,6 +3795,20 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)_braswell_platform_data,
},
+   {
+   .ident = "EF20",
+   .callback = cht_rt5645_ef20_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
+   },
+   },
+   {
+   .ident = "EF20EA",
+   .callback = cht_rt5645_ef20_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
 };
 
 static bool rt5645_check_dp(struct device *dev)
@@ -3831,6 +3858,8 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
if (dmi_data) {
dev_info(>dev, "Detected %s platform\n", dmi_data->ident);
pdata = dmi_data->driver_data;
+   if (dmi_data->callback)
+   dmi_data->callback(dmi_data);
}
 
if (pdata)
-- 
2.20.1

[PATCH v2 0/4] ASoC: rt5645: Enable internal mic and headset on ECS EF20

[Chris Chiu]

These patches are trying to fix the jack detection and internal
microphone problems on ECS EF20 series laptops which are empowered
by Intel Atom x5-Z8350 CPU (CherryTrail) with Realtek rt5645 audio
codec.

---
  v1 -> v2:
Invoke callback() of the DMI quirk if it exists, because
the dmi_first_match() doesn't.

---

Chris Chiu (4):
  ASoC: rt5645: Introduce mapping for ACPI-defined GPIO
  ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series
  ASoC: rt5645: add inv_hp_det flag
  ASoC: rt5645: Enable internal microphone and JD on ECS EF20

 include/sound/rt5645.h|  2 ++
 sound/soc/codecs/rt5645.c | 48 ++-
 2 files changed, 49 insertions(+), 1 deletion(-)

-- 
2.20.1

[PATCH v2 1/4] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

[Chris Chiu]

On at least one laptop (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. The GPIO related
information should be mapped to the rt5645 driver to enable the jack
detection also on non-DT platforms.

Signed-off-by: Chris Chiu 
---
  v1 -> v2:
- none

 sound/soc/codecs/rt5645.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 420003d062c7..78f0ab0a008e 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -42,6 +42,8 @@ static unsigned int quirk = -1;
 module_param(quirk, uint, 0444);
 MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
+static const struct acpi_gpio_mapping *cht_rt5645_gpios;
+
 #define RT5645_DEVICE_ID 0x6308
 #define RT5650_DEVICE_ID 0x6419
 
@@ -3780,7 +3782,6 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)_braswell_platform_data,
},
-   { }
 };
 
 static bool rt5645_check_dp(struct device *dev)
@@ -3848,6 +3849,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
}
 
+   if (cht_rt5645_gpios && has_acpi_companion(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->gpiod_hp_det = devm_gpiod_get_optional(>dev, "hp-detect",
   GPIOD_IN);
 
-- 
2.20.1

[PATCH 0/4] ASoC: rt5645: Enable internal mic and headset on ECS EF20

[Chris Chiu]

These patches are trying to fix the jack detection and internal
microphone problems on ECS EF20 series laptops which are empowered
by Intel Atom x5-Z8350 CPU (CherryTrail) with Realtek rt5645 audio
codec.

Chris Chiu (4):
  ASoC: rt5645: Introduce mapping for ACPI-defined GPIO
  ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series
  ASoC: rt5645: add inv_hp_det flag
  ASoC: rt5645: Enable internal microphone and JD on ECS EF20

 include/sound/rt5645.h|  2 ++
 sound/soc/codecs/rt5645.c | 46 ++-
 2 files changed, 47 insertions(+), 1 deletion(-)

-- 
2.20.1

[PATCH 1/4] ASoC: rt5645: Introduce mapping for ACPI-defined GPIO

[Chris Chiu]

On at least one laptop (ECS EF20EA) the 'hp-detect' GPIO is defined in
the DSDT table by the ACPI GpioIo resources in _CRS. The GPIO related
information should be mapped to the rt5645 driver to enable the jack
detection also on non-DT platforms.

Signed-off-by: Chris Chiu 
---
 sound/soc/codecs/rt5645.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 420003d062c7..78f0ab0a008e 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -42,6 +42,8 @@ static unsigned int quirk = -1;
 module_param(quirk, uint, 0444);
 MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
+static const struct acpi_gpio_mapping *cht_rt5645_gpios;
+
 #define RT5645_DEVICE_ID 0x6308
 #define RT5650_DEVICE_ID 0x6419
 
@@ -3780,7 +3782,6 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)_braswell_platform_data,
},
-   { }
 };
 
 static bool rt5645_check_dp(struct device *dev)
@@ -3848,6 +3849,10 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
}
 
+   if (cht_rt5645_gpios && has_acpi_companion(>dev))
+   if (devm_acpi_dev_add_driver_gpios(>dev, cht_rt5645_gpios))
+   dev_dbg(>dev, "Failed to add driver gpios\n");
+
rt5645->gpiod_hp_det = devm_gpiod_get_optional(>dev, "hp-detect",
   GPIOD_IN);
 
-- 
2.20.1

[PATCH 2/4] ASoC: rt5645: Add ACPI-defined GPIO for ECS EF20 series

[Chris Chiu]

Add the hp-detect gpio for ECS EF20 series laptops based on the
_CRS defined in DSDT table.

Method (_CRS, 0, NotSerialized)
{
  Name (SBUF, ResourceTemplate ()
  {
I2cSerialBusV2 (0x001A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Edge, ActiveBoth, SharedAndWake, PullNone, 0x,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
GpioIo (Shared, PullDefault, 0x, 0x, IoRestrictionInputOnly,
"\\_SB.GPO3", 0x00, ResourceConsumer, ,
)
{   // Pin list
0x004F
}
  })
  Return (SBUF) /* \_SB_.PCI0.I2C2.RTK2._CRS.SBUF */
}

Signed-off-by: Chris Chiu 
---
 sound/soc/codecs/rt5645.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 78f0ab0a008e..24a6acb3c12f 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3653,6 +3653,19 @@ static const struct rt5645_platform_data 
kahlee_platform_data = {
.jd_mode = 3,
 };
 
+static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
+
+static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
+   { "hp-detect-gpios", _hp_detect, 1 },
+   { },
+};
+
+static int cht_rt5645_ef20_quirk_cb(const struct dmi_system_id *id)
+{
+   cht_rt5645_gpios = cht_rt5645_ef20_gpios;
+   return 1;
+}
+
 static const struct dmi_system_id dmi_platform_data[] = {
{
.ident = "Chrome Buddy",
@@ -3782,6 +3795,20 @@ static const struct dmi_system_id dmi_platform_data[] = {
},
.driver_data = (void *)_braswell_platform_data,
},
+   {
+   .ident = "EF20",
+   .callback = cht_rt5645_ef20_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
+   },
+   },
+   {
+   .ident = "EF20EA",
+   .callback = cht_rt5645_ef20_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
+   },
+   },
 };
 
 static bool rt5645_check_dp(struct device *dev)
-- 
2.20.1

[PATCH 3/4] ASoC: rt5645: add inv_hp_det flag

[Chris Chiu]

The ECS EF20EA laptop use gpio for jack detection instead of rt5645
rt5645 JD. However, the GPIO polarity is inverse for hp-detect based
on the _DSD property of the RTK2 device.

Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"hp-detect-gpio", Package() {^RTK2, 0, 0, 1 }},
}
})

This flag will invert the hp-detect gpio polarity.

Signed-off-by: Chris Chiu 
---
 include/sound/rt5645.h| 2 ++
 sound/soc/codecs/rt5645.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/include/sound/rt5645.h b/include/sound/rt5645.h
index 39a77c7cea36..710c95be5509 100644
--- a/include/sound/rt5645.h
+++ b/include/sound/rt5645.h
@@ -22,6 +22,8 @@ struct rt5645_platform_data {
bool level_trigger_irq;
/* Invert JD1_1 status polarity */
bool inv_jd1_1;
+   /* Invert HP detect status polarity */
+   bool inv_hp_pol;
 
/* Value to asign to snd_soc_card.long_name */
const char *long_name;
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 24a6acb3c12f..530145cf8c5b 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -34,6 +34,7 @@
 #define QUIRK_INV_JD1_1(q) ((q) & 1)
 #define QUIRK_LEVEL_IRQ(q) (((q) >> 1) & 1)
 #define QUIRK_IN2_DIFF(q)  (((q) >> 2) & 1)
+#define QUIRK_INV_HP_POL(q)(((q) >> 3) & 1)
 #define QUIRK_JD_MODE(q)   (((q) >> 4) & 7)
 #define QUIRK_DMIC1_DATA_PIN(q)(((q) >> 8) & 3)
 #define QUIRK_DMIC2_DATA_PIN(q)(((q) >> 12) & 3)
@@ -3263,6 +3264,8 @@ static void rt5645_jack_detect_work(struct work_struct 
*work)
case 0: /* Not using rt5645 JD */
if (rt5645->gpiod_hp_det) {
gpio_state = gpiod_get_value(rt5645->gpiod_hp_det);
+   if (rt5645->pdata.inv_hp_pol)
+   gpio_state ^= 1;
dev_dbg(rt5645->component->dev, "gpio_state = %d\n",
gpio_state);
report = rt5645_jack_detect(rt5645->component, 
gpio_state);
@@ -3871,6 +3874,7 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
rt5645->pdata.in2_diff = QUIRK_IN2_DIFF(quirk);
rt5645->pdata.level_trigger_irq = QUIRK_LEVEL_IRQ(quirk);
rt5645->pdata.inv_jd1_1 = QUIRK_INV_JD1_1(quirk);
+   rt5645->pdata.inv_hp_pol = QUIRK_INV_HP_POL(quirk);
rt5645->pdata.jd_mode = QUIRK_JD_MODE(quirk);
rt5645->pdata.dmic1_data_pin = QUIRK_DMIC1_DATA_PIN(quirk);
rt5645->pdata.dmic2_data_pin = QUIRK_DMIC2_DATA_PIN(quirk);
-- 
2.20.1

[PATCH 4/4] ASoC: rt5645: Enable internal microphone and JD on ECS EF20

[Chris Chiu]

On ECS EF20 series laptops, the internal mic is on DMIC2/IN2P.
And they need the inv_hp_det to make jack detection to work as
exoected.

Signed-off-by: Chris Chiu 
---
 sound/soc/codecs/rt5645.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 530145cf8c5b..154d9db9ceb3 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3656,6 +3656,12 @@ static const struct rt5645_platform_data 
kahlee_platform_data = {
.jd_mode = 3,
 };
 
+static const struct rt5645_platform_data ecs_ef20_platform_data = {
+   .dmic1_data_pin = RT5645_DMIC1_DISABLE,
+   .dmic2_data_pin = RT5645_DMIC_DATA_IN2P,
+   .inv_hp_pol = 1,
+};
+
 static const struct acpi_gpio_params ef20_hp_detect = { 1, 0, false };
 
 static const struct acpi_gpio_mapping cht_rt5645_ef20_gpios[] = {
@@ -3804,6 +3810,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
},
+   .driver_data = (void *)_ef20_platform_data,
},
{
.ident = "EF20EA",
@@ -3811,6 +3818,7 @@ static const struct dmi_system_id dmi_platform_data[] = {
.matches = {
DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
},
+   .driver_data = (void *)_ef20_platform_data,
},
 };
 
-- 
2.20.1

Re: [PATCH v2] HID: Add Wireless Radio Control feature for Chicony devices

[Chris Chiu]

On Wed, Dec 23, 2020 at 1:57 PM Jian-Hong Pan  wrote:
>
> Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
> "Wireless Radio Control" feature. For example, the wireless keyboard
> [04f2:1236] shipped with ASUS all-in-one desktop.
>
> After consulting Chicony for this hotkey, learned the device will send
> with 0x11 as the report ID and 0x1 as the value when the key is pressed
> down.
>
> This patch maps the event as KEY_RFKILL.
>
> Signed-off-by: Jian-Hong Pan 
Reviewed-by: Chris Chiu 
> ---
> v2: Remove the duplicated key pressed check.
>
>  drivers/hid/hid-chicony.c | 55 +++
>  drivers/hid/hid-ids.h |  1 +
>  2 files changed, 56 insertions(+)
>
> diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
> index 3f0ed6a95223..ca556d39da2a 100644
> --- a/drivers/hid/hid-chicony.c
> +++ b/drivers/hid/hid-chicony.c
> @@ -21,6 +21,39 @@
>
>  #include "hid-ids.h"
>
> +#define CH_WIRELESS_CTL_REPORT_ID  0x11
> +
> +static int ch_report_wireless(struct hid_report *report, u8 *data, int size)
> +{
> +   struct hid_device *hdev = report->device;
> +   struct input_dev *input;
> +
> +   if (report->id != CH_WIRELESS_CTL_REPORT_ID || report->maxfield != 1)
> +   return 0;
> +
> +   input = report->field[0]->hidinput->input;
> +   if (!input) {
> +   hid_warn(hdev, "can't find wireless radio control's input");
> +   return 0;
> +   }
> +
> +   input_report_key(input, KEY_RFKILL, 1);
> +   input_sync(input);
> +   input_report_key(input, KEY_RFKILL, 0);
> +   input_sync(input);
> +
> +   return 1;
> +}
> +
> +static int ch_raw_event(struct hid_device *hdev,
> +   struct hid_report *report, u8 *data, int size)
> +{
> +   if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
> +   return ch_report_wireless(report, data, size);
> +
> +   return 0;
> +}
> +
>  #define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
> EV_KEY, (c))
>  static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> @@ -77,10 +110,30 @@ static __u8 *ch_switch12_report_fixup(struct hid_device 
> *hdev, __u8 *rdesc,
> return rdesc;
>  }
>
> +static int ch_probe(struct hid_device *hdev, const struct hid_device_id *id)
> +{
> +   int ret;
> +
> +   hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
> +   ret = hid_parse(hdev);
> +   if (ret) {
> +   hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
> +   return ret;
> +   }
> +
> +   ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> +   if (ret) {
> +   hid_err(hdev, "Chicony hw start failed: %d\n", ret);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
>
>  static const struct hid_device_id ch_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_WIRELESS2) },
> +   { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_WIRELESS3) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
> { }
>  };
> @@ -91,6 +144,8 @@ static struct hid_driver ch_driver = {
> .id_table = ch_devices,
> .report_fixup = ch_switch12_report_fixup,
> .input_mapping = ch_input_mapping,
> +   .probe = ch_probe,
> +   .raw_event = ch_raw_event,
>  };
>  module_hid_driver(ch_driver);
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 4c5f23640f9c..06d90301a3dc 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -270,6 +270,7 @@
>  #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
>  #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
>  #define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
> +#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
>  #define USB_DEVICE_ID_ASUS_AK1D0x1125
>  #define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
>  #define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
> --
> 2.29.2
>

Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices

[Chris Chiu]

On Tue, Dec 22, 2020 at 3:41 PM Jian-Hong Pan  wrote:
>
> Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with
> "Wireless Radio Control" feature. For example, the wireless keyboard
> [04f2:1236] shipped with ASUS all-in-one desktop.
>
> After consulting Chicony for this hotkey, learned the device will send
> with 0x11 as the report ID and 0x1 as the value when the key is pressed
> down.
>
> This patch maps the event as KEY_RFKILL.
>
> Signed-off-by: Jian-Hong Pan 
> ---
>  drivers/hid/hid-chicony.c | 58 +++
>  drivers/hid/hid-ids.h |  1 +
>  2 files changed, 59 insertions(+)
>
> diff --git a/drivers/hid/hid-chicony.c b/drivers/hid/hid-chicony.c
> index 3f0ed6a95223..aca963aa0f1e 100644
> --- a/drivers/hid/hid-chicony.c
> +++ b/drivers/hid/hid-chicony.c
> @@ -21,6 +21,42 @@
>
>  #include "hid-ids.h"
>
> +#define KEY_PRESSED0x01
> +#define CH_WIRELESS_CTL_REPORT_ID  0x11
> +
> +static int ch_report_wireless(struct hid_report *report, u8 *data, int size)
> +{
> +   struct hid_device *hdev = report->device;
> +   struct input_dev *input;
> +
> +   if (report->id != CH_WIRELESS_CTL_REPORT_ID ||
> +   report->maxfield != 1 ||
> +   *report->field[0]->value != KEY_PRESSED)

Maybe replace this line with hid_check_keys_pressed() and the KEY_PRESSED
is not required.

> +   return 0;
> +
> +   input = report->field[0]->hidinput->input;
> +   if (!input) {
> +   hid_warn(hdev, "can't find wireless radio control's input");
> +   return 0;
> +   }
> +
> +   input_report_key(input, KEY_RFKILL, 1);
> +   input_sync(input);
> +   input_report_key(input, KEY_RFKILL, 0);
> +   input_sync(input);
> +
> +   return 1;
> +}
> +
> +static int ch_raw_event(struct hid_device *hdev,
> +   struct hid_report *report, u8 *data, int size)
> +{
> +   if (report->application == HID_GD_WIRELESS_RADIO_CTLS)
> +   return ch_report_wireless(report, data, size);
> +
> +   return 0;
> +}
> +
>  #define ch_map_key_clear(c)hid_map_usage_clear(hi, usage, bit, max, \
> EV_KEY, (c))
>  static int ch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> @@ -77,10 +113,30 @@ static __u8 *ch_switch12_report_fixup(struct hid_device 
> *hdev, __u8 *rdesc,
> return rdesc;
>  }
>
> +static int ch_probe(struct hid_device *hdev, const struct hid_device_id *id)
> +{
> +   int ret;
> +
> +   hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
> +   ret = hid_parse(hdev);
> +   if (ret) {
> +   hid_err(hdev, "Chicony hid parse failed: %d\n", ret);
> +   return ret;
> +   }
> +
> +   ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> +   if (ret) {
> +   hid_err(hdev, "Chicony hw start failed: %d\n", ret);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
>
>  static const struct hid_device_id ch_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_WIRELESS2) },
> +   { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_WIRELESS3) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, 
> USB_DEVICE_ID_CHICONY_ACER_SWITCH12) },
> { }
>  };
> @@ -91,6 +147,8 @@ static struct hid_driver ch_driver = {
> .id_table = ch_devices,
> .report_fixup = ch_switch12_report_fixup,
> .input_mapping = ch_input_mapping,
> +   .probe = ch_probe,
> +   .raw_event = ch_raw_event,
>  };
>  module_hid_driver(ch_driver);
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 4c5f23640f9c..06d90301a3dc 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -270,6 +270,7 @@
>  #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE 0x1053
>  #define USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE20x0939
>  #define USB_DEVICE_ID_CHICONY_WIRELESS20x1123
> +#define USB_DEVICE_ID_CHICONY_WIRELESS30x1236
>  #define USB_DEVICE_ID_ASUS_AK1D0x1125
>  #define USB_DEVICE_ID_CHICONY_TOSHIBA_WT10A0x1408
>  #define USB_DEVICE_ID_CHICONY_ACER_SWITCH120x1421
> --
> 2.29.2
>

Re: [PATCH] ASoC: Intel: bytcr_rt5640: Add quirks for DeeQ X5-Z8300

[Chris Chiu]

On Wed, Dec 16, 2020 at 12:18 PM Chris Chiu  wrote:
>
> DeeQ X5-Z8300 is a laptop empowered by Intel Atom Cherry Trail. Add
> quirks to select the correct input map, jack-detect options to enable
> jack sensing and internal/headset microphones.
>
> Signed-off-by: Chris Chiu 
> ---
>  sound/soc/intel/boards/bytcr_rt5651.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
> b/sound/soc/intel/boards/bytcr_rt5651.c
> index 688b5e0a49e3..9df09e26b05a 100644
> --- a/sound/soc/intel/boards/bytcr_rt5651.c
> +++ b/sound/soc/intel/boards/bytcr_rt5651.c
> @@ -507,6 +507,14 @@ static const struct dmi_system_id 
> byt_rt5651_quirk_table[] = {
> BYT_RT5651_SSP0_AIF1 |
> BYT_RT5651_MONO_SPEAKER),
> },
> +   {
> +   .callback = byt_rt5651_quirk_cb,
> +   .matches = {
> +   DMI_MATCH(DMI_SYS_VENDOR, "DeeQ"),
> +   DMI_MATCH(DMI_PRODUCT_NAME, "X5-Z8300"),
> +   },
> +   .driver_data = (void *)(BYT_RT5651_IN1_IN2_MAP | 
> BYT_RT5651_JD1_1),
> +   },
> {}
>  };
>
> --
> 2.20.1
>

Gentle ping. Cheers.

Chris

[PATCH 1/2] ALSA: hda/realtek: Apply jack fixup for Quanta NL3

[Chris Chiu]

The Quanta NL3 laptop has both a headphone output jack and a headset
jack, on the right edge of the chassis.

The pin information suggests that both of these are at the Front.
The PulseAudio is confused to differentiate them so one of the jack
can neither get the jack sense working nor the audio output.

The ALC269_FIXUP_LIFEBOOK chained with ALC269_FIXUP_QUANTA_MUTE can
help to differentiate 2 jacks and get the 'Auto-Mute Mode' working
correctly.

Signed-off-by: Chris Chiu 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 8616c5624870..bb1010d78717 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8013,6 +8013,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", 
ALC283_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1462, 0xb120, "MSI Cubi MS-B120", 
ALC283_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1462, 0xb171, "Cubi N 8GL (MS-B171)", 
ALC283_FIXUP_HEADSET_MIC),
+   SND_PCI_QUIRK(0x152d, 0x1082, "Quanta NL3", ALC269_FIXUP_LIFEBOOK),
SND_PCI_QUIRK(0x1558, 0x1323, "Clevo N130ZU", 
ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x1325, "System76 Darter Pro (darp5)", 
ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1558, 0x1401, "Clevo L140[CZ]U", 
ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
-- 
2.20.1

[PATCH 2/2] ALSA/hda: apply jack fixup for the Acer Veriton N4640G/N6640G/N2510G

[Chris Chiu]

This Acer Veriton N4640G/N6640G/N2510G desktops have 2 headphone
jacks(front and rear), and a separate Mic In jack.

The rear headphone jack is actually a line out jack but always silent
while playing audio. The front 'Mic In' also fails the jack sensing.
Apply the ALC269_FIXUP_LIFEBOOK to have all audio jacks to work as
expected.

Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index bb1010d78717..9eb43d827bda 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7803,11 +7803,14 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x0762, "Acer Aspire E1-472", 
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", 
ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572),
SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", 
ALC282_FIXUP_ASPIRE_V5_PINS),
+   SND_PCI_QUIRK(0x1025, 0x101c, "Acer Veriton N2510G", 
ALC269_FIXUP_LIFEBOOK),
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860", 
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820", 
ALC269VC_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14", 
ALC283_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G", 
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432", 
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1025, 0x1166, "Acer Veriton N4640G", 
ALC269_FIXUP_LIFEBOOK),
+   SND_PCI_QUIRK(0x1025, 0x1167, "Acer Veriton N6640G", 
ALC269_FIXUP_LIFEBOOK),
SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500", 
ALC299_FIXUP_PREDATOR_SPK),
SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox", 
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS),
SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G", 
ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE),
-- 
2.20.1

[PATCH] ALSA: hda/realtek: Remove dummy lineout on Acer TravelMate P648/P658

[Chris Chiu]

Acer TravelMate laptops P648/P658 series with codec ALC282 only have
one physical jack for headset but there's a confusing lineout pin on
NID 0x1b reported. Audio applications hence misunderstand that there
are a speaker and a lineout, and take the lineout as the default audio
output.

Add a new quirk to remove the useless lineout and enable the pin 0x18
for jack sensing and headset microphone.

Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 8616c5624870..e7edcdbc6ca3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6366,6 +6366,7 @@ enum {
ALC287_FIXUP_HP_GPIO_LED,
ALC256_FIXUP_HP_HEADSET_MIC,
ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
+   ALC282_FIXUP_ACER_DISABLE_LINEOUT,
 };
 
 static const struct hda_fixup alc269_fixups[] = {
@@ -7789,6 +7790,16 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
},
+   [ALC282_FIXUP_ACER_DISABLE_LINEOUT] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x1b, 0x41f0 },
+   { 0x18, 0x01a1913c }, /* use as headset mic, without 
its own jack detect */
+   { },
+   },
+   .chained = true,
+   .chain_id = ALC269_FIXUP_HEADSET_MODE
+   },
 };
 
 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -8560,6 +8571,22 @@ static const struct snd_hda_pin_quirk 
alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60140},
{0x19, 0x04a11030},
{0x21, 0x04211020}),
+   SND_HDA_PIN_QUIRK(0x10ec0282, 0x1025, "Acer", 
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
+   ALC282_STANDARD_PINS,
+   {0x12, 0x90a609c0},
+   {0x18, 0x03a11830},
+   {0x19, 0x04a19831},
+   {0x1a, 0x0481303f},
+   {0x1b, 0x04211020},
+   {0x21, 0x0321101f}),
+   SND_HDA_PIN_QUIRK(0x10ec0282, 0x1025, "Acer", 
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
+   ALC282_STANDARD_PINS,
+   {0x12, 0x90a60940},
+   {0x18, 0x03a11830},
+   {0x19, 0x04a19831},
+   {0x1a, 0x0481303f},
+   {0x1b, 0x04211020},
+   {0x21, 0x0321101f}),
SND_HDA_PIN_QUIRK(0x10ec0283, 0x1028, "Dell", 
ALC269_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC282_STANDARD_PINS,
{0x12, 0x90a60130},
-- 
2.20.1

[PATCH] ASoC: Intel: bytcr_rt5640: Add quirks for DeeQ X5-Z8300

[Chris Chiu]

DeeQ X5-Z8300 is a laptop empowered by Intel Atom Cherry Trail. Add
quirks to select the correct input map, jack-detect options to enable
jack sensing and internal/headset microphones.

Signed-off-by: Chris Chiu 
---
 sound/soc/intel/boards/bytcr_rt5651.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c 
b/sound/soc/intel/boards/bytcr_rt5651.c
index 688b5e0a49e3..9df09e26b05a 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -507,6 +507,14 @@ static const struct dmi_system_id byt_rt5651_quirk_table[] 
= {
BYT_RT5651_SSP0_AIF1 |
BYT_RT5651_MONO_SPEAKER),
},
+   {
+   .callback = byt_rt5651_quirk_cb,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "DeeQ"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "X5-Z8300"),
+   },
+   .driver_data = (void *)(BYT_RT5651_IN1_IN2_MAP | 
BYT_RT5651_JD1_1),
+   },
{}
 };
 
-- 
2.20.1

[PATCH v2] x86/reboot/quirks: Add GIGABYTE BRIX BXBT-2807 reboot quirk

[Chris Chiu]

From: Dan Nicholson 

The GIGABYTE BRIX BXBT-2807 always hangs with the normal acpi
reboot. It works without problem after adding the parameter
reboot=bios.

Signed-off-by: Dan Nicholson 
Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---

v2:
  - fix typo in the commit message.

 arch/x86/kernel/reboot.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index db115943e8bd..a03344616cd9 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -467,6 +467,16 @@ static const struct dmi_system_id reboot_dmi_table[] 
__initconst = {
},
},
 
+   /* GIGABYTE */
+   {   /* Workaround hard disk crash on ACPI reboot */
+   .callback = set_bios_reboot,
+   .ident = "GIGABYTE BRIX BXBT-2807",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
+   },
+   },
+
/* Hewlett-Packard */
{   /* Handle problems with rebooting on HP laptops */
.callback = set_bios_reboot,
-- 
2.20.1

[PATCH] x86/reboot/quirks: Add GIGABYTE BRIX BXBT-2807 reboot quirk

[Chris Chiu]

From: Dan Nicholson 

The GIGABYTE BRIX BXBT-2807 always hangs with the normal acpi
reboot. It works withour problem after adding the parameter
reboot=bios.

Signed-off-by: Dan Nicholson 
Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---
 arch/x86/kernel/reboot.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index db115943e8bd..a03344616cd9 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -467,6 +467,16 @@ static const struct dmi_system_id reboot_dmi_table[] 
__initconst = {
},
},
 
+   /* GIGABYTE */
+   {   /* Workaround hard disk crash on ACPI reboot */
+   .callback = set_bios_reboot,
+   .ident = "GIGABYTE BRIX BXBT-2807",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
+   },
+   },
+
/* Hewlett-Packard */
{   /* Handle problems with rebooting on HP laptops */
.callback = set_bios_reboot,
-- 
2.20.1

Re: [PATCH] power: supply: axp288_fuel_gauge: Add the ECS EF20EA to the blacklist

[Chris Chiu]

On Wed, Dec 9, 2020 at 10:57 PM Hans de Goede  wrote:
>
> Hi,
>
> On 12/9/20 5:50 AM, Chris Chiu wrote:
> > The ECS EF20EA laptop ships an AXP288 but it is actually using a
> > different, separate FG chip for AC and battery monitoring. On this
> > laptop we need to keep using the regular ACPI driver and disable the
> > AXP288 FG to avoid reporting two batteries to userspace.
> >
> > Signed-off-by: Chris Chiu 
> > ---
> >  drivers/power/supply/axp288_fuel_gauge.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/power/supply/axp288_fuel_gauge.c 
> > b/drivers/power/supply/axp288_fuel_gauge.c
> > index 148eb8105803..a15c322c79ea 100644
> > --- a/drivers/power/supply/axp288_fuel_gauge.c
> > +++ b/drivers/power/supply/axp288_fuel_gauge.c
> > @@ -739,6 +739,12 @@ static const struct dmi_system_id 
> > axp288_fuel_gauge_blacklist[] = {
> >   DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"),
> >   }
> >   },
> > + {
> > + /* ECS EF20 */
> > + .matches = {
> > + DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
> > + },
> > + },
> >   {}
> >  };
>
> The axp288_fuel_gauge_blacklist already has the following entry:
>
> {
> /* ECS EF20EA */
> .matches = {
> DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
> },
> },
>
> So is this real entry really necessary? The existing entry
> matches the quirk for this in drivers/acpi/battery.c:
>
> {
> /* ECS EF20EA, AXP288 PMIC but uses separate fuel-gauge */
> .callback = battery_do_not_check_pmic_quirk,
> .matches = {
> DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
> },
> },
>
> And the one in drivers/acpi/ac.c:
>
> {
> /* ECS EF20EA, AXP288 PMIC but uses separate fuel-gauge */
> .callback = ac_do_not_check_pmic_quirk,
> .matches = {
> DMI_MATCH(DMI_PRODUCT_NAME, "EF20EA"),
> },
> },
>
> So I don't think that this patch is necessary...
>
> Regards,
>
> Hans
>
>

Thanks for pointing that out. We kept this downstreamly for a long time and
didn't notice it's already there.

[PATCH] ALSA: hda/realtek - Enable headset mic of ASUS Q524UQK with ALC255

[Chris Chiu]

The ASUS laptop Q524UQK with ALC255 codec can't detect the headset
microphone until ALC255_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.

Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 8616c5624870..2d4bb9019cb8 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7976,6 +7976,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
SND_PCI_QUIRK(0x1043, 0x1bbd, "ASUS Z550MA", 
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1c23, "Asus X55U", 
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
+   SND_PCI_QUIRK(0x1043, 0x125e, "ASUS Q524UQK", 
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1ccd, "ASUS X555UB", ALC256_FIXUP_ASUS_MIC),
SND_PCI_QUIRK(0x1043, 0x1d4e, "ASUS TM420", ALC256_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x1e11, "ASUS Zephyrus G15", 
ALC289_FIXUP_ASUS_GA502),
-- 
2.20.1

[PATCH] power: supply: axp288_fuel_gauge: Add the ECS EF20EA to the blacklist

[Chris Chiu]

The ECS EF20EA laptop ships an AXP288 but it is actually using a
different, separate FG chip for AC and battery monitoring. On this
laptop we need to keep using the regular ACPI driver and disable the
AXP288 FG to avoid reporting two batteries to userspace.

Signed-off-by: Chris Chiu 
---
 drivers/power/supply/axp288_fuel_gauge.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/power/supply/axp288_fuel_gauge.c 
b/drivers/power/supply/axp288_fuel_gauge.c
index 148eb8105803..a15c322c79ea 100644
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -739,6 +739,12 @@ static const struct dmi_system_id 
axp288_fuel_gauge_blacklist[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"),
}
},
+   {
+   /* ECS EF20 */
+   .matches = {
+   DMI_MATCH(DMI_PRODUCT_NAME, "EF20"),
+   },
+   },
{}
 };
 
-- 
2.20.1

[PATCH] x86/platform: classmate-laptop: add WiFi media button

[Chris Chiu]

From: Carlo Caione 

The WiFi media button on the Quanta NL3 reports keycodes 0x8b and 0x9b
to the platform driver. Add the mapping to support these codes.

Signed-off-by: Carlo Caione 
Reviewed-by: Chris Chiu 
---
 drivers/platform/x86/classmate-laptop.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/platform/x86/classmate-laptop.c 
b/drivers/platform/x86/classmate-laptop.c
index af063f690846..3e03e8d3a07f 100644
--- a/drivers/platform/x86/classmate-laptop.c
+++ b/drivers/platform/x86/classmate-laptop.c
@@ -1023,6 +1023,8 @@ static int cmpc_keys_codes[] = {
KEY_CAMERA,
KEY_BACK,
KEY_FORWARD,
+   KEY_UNKNOWN,
+   KEY_WLAN, /* NL3: 0x8b (press), 0x9b (release) */
KEY_MAX
 };
 
-- 
2.20.1

[PATCH] ASoC: Intel: bytcr_rt5640: Add quirk for ARCHOS Cesium 140

[Chris Chiu]

Tha ARCHOS Cesium 140 tablet has problem with the jack-sensing,
thus the heaset functions are not working.

Add quirk for this model to select the correct input map, jack-detect
options and channel map to enable jack sensing and headset microphone.
This device uses IN1 for its internal MIC and JD2 for jack-detect.

Signed-off-by: Chris Chiu 
---
 sound/soc/intel/boards/bytcr_rt5640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c 
b/sound/soc/intel/boards/bytcr_rt5640.c
index f790514a147d..cd6f7caa43c8 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -421,6 +421,18 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] 
= {
BYT_RT5640_SSP0_AIF1 |
BYT_RT5640_MCLK_EN),
},
+   {
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ARCHOS"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ARCHOS 140 CESIUM"),
+   },
+   .driver_data = (void *)(BYT_RT5640_IN1_MAP |
+   BYT_RT5640_JD_SRC_JD2_IN4N |
+   BYT_RT5640_OVCD_TH_2000UA |
+   BYT_RT5640_OVCD_SF_0P75 |
+   BYT_RT5640_SSP0_AIF1 |
+   BYT_RT5640_MCLK_EN),
+   },
{
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER 
INC."),
-- 
2.20.1

Re: [PATCH] ALSA: hda/realtek - Add support for Memeza EDL03 headset mic

[Chris Chiu]

On Mon, Dec 7, 2020 at 4:38 PM Takashi Iwai  wrote:
>
> On Mon, 07 Dec 2020 08:33:46 +0100,
> Chris Chiu wrote:
> >
> > The Memeza laptop EDL03 with codec ALC256 can't detect the headset
> > microphone. The headphone jack sensing works after we add a pin
> > definition for it by ALC256_FIXUP_ASUS_MIC_NO_PRESENCE.
> >
> > Signed-off-by: Chris Chiu 
> > Signed-off-by: Jian-Hong Pan 
> > ---
> >  sound/pci/hda/patch_realtek.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index d5e4d0ba1008..8b9b94cfc67e 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -7871,6 +7871,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] 
> > = {
> >   SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", 
> > ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
> >   SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
> > ALC269_FIXUP_LIFEBOOK_EXTMIC),
> >   SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", 
> > ALC700_FIXUP_INTEL_REFERENCE),
> > + SND_PCI_QUIRK(0x10ec, 0x115a, "Memeza EDL03", 
> > ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
>
> This looks suspicious.  10ec is the vendor ID for Realtek, i.e. it
> implies that the BIOS on this machine didn't give the proper unique
> ID.  As you can see, the other entries with 10ec are only reference
> boards.
>
> If the newer BIOS still doesn't fix the PCI SSID, you can check the
> codec SSID instead.
>
>
> thanks,
>
> Takashi

Thanks for the feedback. This is a special case that the ODM didn't
flash the DMI information
and assign a formal SSID. They simply ship with the current status w/o
any BIOS customization.

I agree that we should push the vendor for a BIOS fix or figure out a
generic solution for this
instead of a pin quirk. Please ignore this. Thanks

Chris

[PATCH] ALSA: hda/realtek - Add support for Memeza EDL03 headset mic

[Chris Chiu]

The Memeza laptop EDL03 with codec ALC256 can't detect the headset
microphone. The headphone jack sensing works after we add a pin
definition for it by ALC256_FIXUP_ASUS_MIC_NO_PRESENCE.

Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d5e4d0ba1008..8b9b94cfc67e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7871,6 +7871,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x10cf, 0x1629, "Lifebook U7x7", 
ALC255_FIXUP_LIFEBOOK_U7x7_HEADSET_MIC),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", 
ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x10ec, 0x10f2, "Intel Reference board", 
ALC700_FIXUP_INTEL_REFERENCE),
+   SND_PCI_QUIRK(0x10ec, 0x115a, "Memeza EDL03", 
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x10ec, 0x1230, "Intel Reference board", 
ALC295_FIXUP_CHROME_BOOK),
SND_PCI_QUIRK(0x10f7, 0x8338, "Panasonic CF-SZ6", 
ALC269_FIXUP_HEADSET_MODE),
SND_PCI_QUIRK(0x144d, 0xc109, "Samsung Ativ book 9 (NP900X3G)", 
ALC269_FIXUP_INV_DMIC),
-- 
2.20.1

[PATCH] ALSA: hda/realtek - Enable headset mic of ASUS X430UN with ALC256

[Chris Chiu]

The ASUS laptop X430UN with ALC256 can't detect the headset microphone
until ALC256_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied.

Signed-off-by: Chris Chiu 
Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index f2398721ac1e..d5e4d0ba1008 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7827,6 +7827,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x10d0, "ASUS X540LA/X540LJ", 
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x115d, "Asus 1015E", 
ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
SND_PCI_QUIRK(0x1043, 0x11c0, "ASUS X556UR", 
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE),
+   SND_PCI_QUIRK(0x1043, 0x1271, "ASUS X430UN", 
ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1290, "ASUS X441SA", 
ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x12a0, "ASUS X441UV", 
ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x12f0, "ASUS X541UV", ALC256_FIXUP_ASUS_MIC),
-- 
2.20.1

[PATCH] Input: i8042 - add Acer laptops to the i8042 reset list

[Chris Chiu]

The touchpad operates in Basic Mode by default in the Acer BIOS
setup, but some Aspire/TravelMate models require the i8042 to be
reset in order to be correctly detected.

Signed-off-by: Chris Chiu 
---
 drivers/input/serio/i8042-x86ia64io.h | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/drivers/input/serio/i8042-x86ia64io.h 
b/drivers/input/serio/i8042-x86ia64io.h
index a4c9b9652560..f5ce656dc73f 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -607,6 +607,48 @@ static const struct dmi_system_id __initconst 
i8042_dmi_reset_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "AOA150"),
},
},
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-332"),
+   },
+   },
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-132"),
+   },
+   },
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-432"),
+   },
+   },
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A315-31"),
+   },
+   },
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A314-31"),
+   },
+   },
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A114-31"),
+   },
+   },
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate Spin B118-RN"),
+   },
+   },
{
/* Advent 4211 */
.matches = {
-- 
2.20.1

[PATCH] acer-wireless: send an EV_SYN/SYN_REPORT between state changes

[Chris Chiu]

From: Daniel Drake 

Sending the switch state change twice within the same frame is invalid
evdev protocol and only works if the client handles keys immediately as
well. Processing events immediately is incorrect, it forces a fake
order of events that does not exist on the device.

Recent versions of libinput changed to only process the device state and
SYN_REPORT time, so now the key event is lost.

Same fix as 'commit  ("platform/x86: asus-wireless: send
an EV_SYN/SYN_REPORT between state changes")'

Signed-off-by: Daniel Drake 
Signed-off-by: Chris Chiu 
---
 drivers/platform/x86/acer-wireless.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/acer-wireless.c 
b/drivers/platform/x86/acer-wireless.c
index e0976180532a..1b5d935d085a 100644
--- a/drivers/platform/x86/acer-wireless.c
+++ b/drivers/platform/x86/acer-wireless.c
@@ -28,6 +28,7 @@ static void acer_wireless_notify(struct acpi_device *adev, 
u32 event)
return;
}
input_report_key(idev, KEY_RFKILL, 1);
+   input_sync(idev);
input_report_key(idev, KEY_RFKILL, 0);
input_sync(idev);
 }
-- 
2.20.1

[PATCH] ACPI: Add DMI quirk for GIGABYTE GB-BXBT-2807

[Chris Chiu]

From: "Jasper St. Pierre" 

The GIGABYTE GB-BXBT-2807 is a mini-PC which uses off the shelf
components, like an Intel GPU which is meant for mobile systems.
As such, it, by default, has a backlight controller exposed.

Unfortunately, the backlight controller only confuses userspace, which
sees the existence of a backlight device node and has the unrealistic
belief that there is actually a backlight there!

Add a DMI quirk to force the backlight off on this system.

Signed-off-by: Jasper St. Pierre 
Reviewed-by: Chris Chiu 
---
 drivers/acpi/video_detect.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 2499d7e3c710..ac2e194acdbf 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -143,6 +143,13 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
},
{
.callback = video_detect_force_vendor,
+   .ident = "GIGABYTE GB-BXBT-2807",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
+   },
+   },
+   {
.ident = "Sony VPCEH3U1E",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
-- 
2.20.1

[PATCH v2] Bluetooth: btusb: Add support for 13d3:3560 MediaTek MT7615E device

[Chris Chiu]

The ASUS X532EQ laptop contains AzureWave AW-CB434NF WiFi/BT combo
module with an associated MT7615E BT chip using a USB ID of 13d3:3560.

T:  Bus=03 Lev=01 Prnt=01 Port=09 Cnt=02 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3560 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=0
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Chris Chiu 
---

v2:
  - Add comment for the MT7615E BT device.

 drivers/bluetooth/btusb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5af2e3f30a5e..7e05be1a7bff 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -368,6 +368,9 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
  .driver_info = BTUSB_MEDIATEK },
 
+   /* Additional MediaTek MT7615E Bluetooth devices */
+   { USB_DEVICE(0x13d3, 0x3560), .driver_info = BTUSB_MEDIATEK},
+
/* Additional Realtek 8723AE Bluetooth devices */
{ USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x13d3, 0x3394), .driver_info = BTUSB_REALTEK },
-- 
2.20.1

[PATCH] Bluetooth: btusb: Add support for 13d3:3560 MediaTek MT7615E device

[Chris Chiu]

The ASUS X532EQ laptop contains AzureWave AW-CB434NF module with an
associated MT7615E BT chip using a USB ID of 13d3:3560.

T:  Bus=03 Lev=01 Prnt=01 Port=09 Cnt=02 Dev#=  3 Spd=480  MxCh= 0
D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3560 Rev= 1.00
S:  Manufacturer=MediaTek Inc.
S:  Product=Wireless_Device
S:  SerialNumber=0
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms

Signed-off-by: Chris Chiu 
---
 drivers/bluetooth/btusb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5af2e3f30a5e..a0bfd41fdfee 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -367,6 +367,7 @@ static const struct usb_device_id blacklist_table[] = {
/* MediaTek Bluetooth devices */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
  .driver_info = BTUSB_MEDIATEK },
+   { USB_DEVICE(0x13d3, 0x3560), .driver_info = BTUSB_MEDIATEK},
 
/* Additional Realtek 8723AE Bluetooth devices */
{ USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
-- 
2.20.1

[PATCH] rtlwifi: rtl8192se: remove duplicated legacy_httxpowerdiff

[Chris Chiu]

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/rtlwifi/rtl8192se/rf.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
index 81313e0ca834..0cdcddfebca9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
@@ -1906,7 +1906,7 @@ static void _rtl92se_read_adapter_info(struct 
ieee80211_hw *hw)
 * index diff of legacy to HT OFDM rate. */
tempval = hwinfo[EEPROM_RFIND_POWERDIFF] & 0xff;
rtlefuse->eeprom_txpowerdiff = tempval;
-   rtlefuse->legacy_httxpowerdiff =
+   rtlefuse->legacy_ht_txpowerdiff =
rtlefuse->txpwr_legacyhtdiff[RF90_PATH_A][0];
 
RTPRINT(rtlpriv, FINIT, INIT_TXPOWER,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
index a37855f57e76..54576566083c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
@@ -25,7 +25,7 @@ static void _rtl92s_get_powerbase(struct ieee80211_hw *hw, u8 
*p_pwrlevel,
 
/* We only care about the path A for legacy. */
if (rtlefuse->eeprom_version < 2) {
-   pwrbase0 = pwrlevel[0] + (rtlefuse->legacy_httxpowerdiff & 0xf);
+   pwrbase0 = pwrlevel[0] + (rtlefuse->legacy_ht_txpowerdiff & 
0xf);
} else {
legacy_pwrdiff = rtlefuse->txpwr_legacyhtdiff
[RF90_PATH_A][chnl - 1];
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 13421cf2d201..0a516c3c7cea 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1966,7 +1966,6 @@ struct rtl_efuse {
 
u8 txpwr_safetyflag;/* Band edge enable flag */
u16 eeprom_txpowerdiff;
-   u8 legacy_httxpowerdiff;/* Legacy to HT rate power diff */
u8 antenna_txpwdiff[3];
 
u8 eeprom_regulatory;
-- 
2.20.1

[PATCH 1/3] rtlwifi: rtl8192se: remove duplicated legacy_httxpowerdiff

[Chris Chiu]

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/rtlwifi/rtl8192se/rf.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
index 81313e0ca834..0cdcddfebca9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
@@ -1906,7 +1906,7 @@ static void _rtl92se_read_adapter_info(struct 
ieee80211_hw *hw)
 * index diff of legacy to HT OFDM rate. */
tempval = hwinfo[EEPROM_RFIND_POWERDIFF] & 0xff;
rtlefuse->eeprom_txpowerdiff = tempval;
-   rtlefuse->legacy_httxpowerdiff =
+   rtlefuse->legacy_ht_txpowerdiff =
rtlefuse->txpwr_legacyhtdiff[RF90_PATH_A][0];
 
RTPRINT(rtlpriv, FINIT, INIT_TXPOWER,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
index a37855f57e76..54576566083c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/rf.c
@@ -25,7 +25,7 @@ static void _rtl92s_get_powerbase(struct ieee80211_hw *hw, u8 
*p_pwrlevel,
 
/* We only care about the path A for legacy. */
if (rtlefuse->eeprom_version < 2) {
-   pwrbase0 = pwrlevel[0] + (rtlefuse->legacy_httxpowerdiff & 0xf);
+   pwrbase0 = pwrlevel[0] + (rtlefuse->legacy_ht_txpowerdiff & 
0xf);
} else {
legacy_pwrdiff = rtlefuse->txpwr_legacyhtdiff
[RF90_PATH_A][chnl - 1];
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h 
b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 13421cf2d201..0a516c3c7cea 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1966,7 +1966,6 @@ struct rtl_efuse {
 
u8 txpwr_safetyflag;/* Band edge enable flag */
u16 eeprom_txpowerdiff;
-   u8 legacy_httxpowerdiff;/* Legacy to HT rate power diff */
u8 antenna_txpwdiff[3];
 
u8 eeprom_regulatory;
-- 
2.20.1

Re: mt7615: Fail to load firmware on AZWAVE-CB434NF module

[Chris Chiu]

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] mt7615e :2d:00.0: Message -4294967280 (seq 1) timeout
> [   25.630851] mt7615e :2d:00.0: Failed to get patch semaphore
> [   25.630853] mt7615e :2d:00.0: mediatek/mt7663pr2h.bin not
> found, switching to mediatek/mt7663pr2h_rebb.bin
> [   46.54] mt7615e :2d:00.0: Message -4294967280 (seq 2) timeout
> [   46.78] mt7615e :2d:00.0: Failed to get patch semaphore
> [   46.79] mt7615e :2d:00.0: failed to load 
> mediatek/mt7663pr2h_rebb.bin
>
> The lspci information for the device shows as follows
> :2d:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7663]
> Subsystem: AzureWave Device [1a3b:4341]
> Flags: bus master, fast devsel, latency 0, IRQ 177
> Memory at 603210 (64-bit, prefetchable) [size=1M]
> Memory at 603220 (64-bit, prefetchable) [size=16K]
> Memory at 6032204000 (64-bit, prefetchable) [size=4K]
> Capabilities: [80] Express Endpoint, MSI 1f
> Capabilities: [e0] MSI: Enable+ Count=1/32 Maskable+ 64bit+
> Capabilities: [f8] Power Management version 3
> Capabilities: [100] Vendor Specific Information: ID=1556 Rev=1
> Len=008 
> Capabilities: [108] Latency Tolerance Reporting
> Capabilities: [110] L1 PM Substates
> Capabilities: [200] Advanced Error Reporting
> Kernel driver in use: mt7615e
> Kernel modules: mt7615e
>
> I also tried the latest linux-firmware with the most up to date
> mediatek firmware
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=7a237c6ee2c7af48723c356461ef80270a52d2c6.
> But still get the same error.
>
> Any suggestions on what I can do here?
>
> Chris

Gentle ping. What should I do for the next step?

mt7615: Fail to load firmware on AZWAVE-CB434NF module

[Chris Chiu]

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.0: Failed to get patch semaphore
[   25.630853] mt7615e :2d:00.0: mediatek/mt7663pr2h.bin not
found, switching to mediatek/mt7663pr2h_rebb.bin
[   46.54] mt7615e :2d:00.0: Message -4294967280 (seq 2) timeout
[   46.78] mt7615e :2d:00.0: Failed to get patch semaphore
[   46.79] mt7615e :2d:00.0: failed to load mediatek/mt7663pr2h_rebb.bin

The lspci information for the device shows as follows
:2d:00.0 Network controller [0280]: MEDIATEK Corp. Device [14c3:7663]
Subsystem: AzureWave Device [1a3b:4341]
Flags: bus master, fast devsel, latency 0, IRQ 177
Memory at 603210 (64-bit, prefetchable) [size=1M]
Memory at 603220 (64-bit, prefetchable) [size=16K]
Memory at 6032204000 (64-bit, prefetchable) [size=4K]
Capabilities: [80] Express Endpoint, MSI 1f
Capabilities: [e0] MSI: Enable+ Count=1/32 Maskable+ 64bit+
Capabilities: [f8] Power Management version 3
Capabilities: [100] Vendor Specific Information: ID=1556 Rev=1
Len=008 
Capabilities: [108] Latency Tolerance Reporting
Capabilities: [110] L1 PM Substates
Capabilities: [200] Advanced Error Reporting
Kernel driver in use: mt7615e
Kernel modules: mt7615e

I also tried the latest linux-firmware with the most up to date
mediatek firmware
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=7a237c6ee2c7af48723c356461ef80270a52d2c6.
But still get the same error.

Any suggestions on what I can do here?

Chris

[PATCH] rtl8xxxu: prevent potential memory leak

[Chris Chiu]

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/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 19efae462a24..5cd7ef3625c5 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5795,7 +5795,6 @@ static int rtl8xxxu_submit_int_urb(struct ieee80211_hw 
*hw)
ret = usb_submit_urb(urb, GFP_KERNEL);
if (ret) {
usb_unanchor_urb(urb);
-   usb_free_urb(urb);
goto error;
}
 
@@ -5804,6 +5803,7 @@ static int rtl8xxxu_submit_int_urb(struct ieee80211_hw 
*hw)
rtl8xxxu_write32(priv, REG_USB_HIMR, val32);
 
 error:
+   usb_free_urb(urb);
return ret;
 }
 
@@ -6318,6 +6318,7 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
struct rtl8xxxu_priv *priv = hw->priv;
struct rtl8xxxu_rx_urb *rx_urb;
struct rtl8xxxu_tx_urb *tx_urb;
+   struct sk_buff *skb;
unsigned long flags;
int ret, i;
 
@@ -6368,6 +6369,13 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
rx_urb->hw = hw;
 
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
+   if (ret) {
+   if (ret != -ENOMEM) {
+   skb = (struct sk_buff *)rx_urb->urb.context;
+   dev_kfree_skb(skb);
+   }
+   rtl8xxxu_queue_rx_urb(priv, rx_urb);
+   }
}
 
schedule_delayed_work(>ra_watchdog, 2 * HZ);
-- 
2.20.1

[PATCH] ALSA: usb: mixer: volume quirk for ESS Technology Asus USB DAC

[Chris Chiu]

The Asus USB DAC is a USB type-C audio dongle for connecting to
the headset and headphone. The volume minimum value -23040 which
is 0xa600 in hexadecimal with the resolution value 1 indicates
this should be endianness issue caused by the firmware bug. Add
a volume quirk to fix the volume control problem.

Also fixes this warning:
  Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
  [5] FU [Headset Capture Volume] ch = 1, val = -23040/0/1
  Warning! Unlikely big volume range (=23040), cval->res is probably wrong.
  [7] FU [Headset Playback Volume] ch = 1, val = -23040/0/1

Signed-off-by: Chris Chiu 
---
 sound/usb/mixer.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 81b2db0edd5f..0b568a9fdab3 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1171,6 +1171,14 @@ static void volume_control_quirks(struct 
usb_mixer_elem_info *cval,
cval->res = 384;
}
break;
+   case USB_ID(0x0495, 0x3042): /* ESS Technology Asus USB DAC */
+   if ((strstr(kctl->id.name, "Playback Volume") != NULL) ||
+   strstr(kctl->id.name, "Capture Volume") != NULL) {
+   cval->min >>= 8;
+   cval->max = 0;
+   cval->res = 1;
+   }
+   break;
}
 }
 
-- 
2.20.1

[PATCH] platform/x86: asus_wmi: Reserve more space for struct bias_args

[Chris Chiu]

On the ASUS laptop UX325JA/UX425JA, most of the media keys are not
working due to the ASUS WMI driver fails to be loaded. The ACPI error
as follows leads to the failure of asus_wmi_evaluate_method.
  ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field [IIA3] at bit offset/length 
96/32 exceeds size of target Buffer (96 bits) (20200326/dsopcode-203)
  No Local Variables are initialized for Method [WMNB]
  ACPI Error: Aborting method \_SB.ATKD.WMNB due to previous error 
(AE_AML_BUFFER_LIMIT) (20200326/psparse-531)

The DSDT for the WMNB part shows that 5 DWORD required for local
variables and the 3rd variable IIA3 hit the buffer limit.

Method (WMNB, 3, Serialized)
{ ..
CreateDWordField (Arg2, Zero, IIA0)
CreateDWordField (Arg2, 0x04, IIA1)
CreateDWordField (Arg2, 0x08, IIA2)
CreateDWordField (Arg2, 0x0C, IIA3)
CreateDWordField (Arg2, 0x10, IIA4)
Local0 = (Arg1 & 0x)
If ((Local0 == 0x54494E49))
  ..
}

The limitation is determined by the input acpi_buffer size passed
to the wmi_evaluate_method. Since the struct bios_args is the data
structure used as input buffer by default for all ASUS WMI calls,
the size needs to be expanded to fix the problem.

Signed-off-by: Chris Chiu 
---
 drivers/platform/x86/asus-wmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index bb7c529d7d16..cd212ee210e2 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -116,6 +116,8 @@ struct bios_args {
u32 arg0;
u32 arg1;
u32 arg2; /* At least TUF Gaming series uses 3 dword input buffer. */
+   u32 arg4;
+   u32 arg5;
 } __packed;
 
 /*
-- 
2.25.2

asus-wmi fails to load on new ASUS laptop UX325JA

[Chris Chiu]

Hi,
I have the ASUS new laptop UX325JA and most of the media keys are
not working even with the latest kernel (5.7.0-rc5+). Looking into the
dmesg log, the ASUS WMI driver fails to load because of
[7.827241] asus-nb-wmi: probe of asus-nb-wmi failed with error -5.

Before this message, the following message repeat 5 times, please
check the full dmesg log here
https://gist.github.com/mschiu77/9a53cd8ff17029e949210dfb3ec1213f
[7.825975] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Field
[IIA3] at bit offset/length 96/32 exceeds size of target Buffer (96
bits) (20200326/dsopcode-203)
[7.825985] No Local Variables are initialized for Method [WMNB]
[7.826005] ACPI Error: Aborting method \_SB.ATKD.WMNB due to
previous error (AE_AML_BUFFER_LIMIT) (20200326/psparse-531)

It fails the \_SB.ATKD.WMNB because the local variable IIA3
exceeds the buffer limit. The WMNB is the function to deal with all
ASUS WMI functions, such as ASUS_WMI_METHODID_INIT...etc. The related
code in DSDT is as follows. The full DSDT is here
https://gist.github.com/mschiu77/849c6cb89a8d8cadd015fa75465882dd

Method (WMNB, 3, Serialized)
{
P8XH (Zero, 0x11)
CreateDWordField (Arg2, Zero, IIA0)
CreateDWordField (Arg2, 0x04, IIA1)
CreateDWordField (Arg2, 0x08, IIA2)
CreateDWordField (Arg2, 0x0C, IIA3)
CreateDWordField (Arg2, 0x10, IIA4)
Local0 = (Arg1 & 0x)
If ((Local0 == 0x54494E49))

Just as the error messages indicated,  the IIA3 is out of boundary
for the target Buffer. The limit 96bits (12 bytes) is determined by
the input acpi_buffer size, which refers to internally defined struct
bios_args, in asus_wmi_evaluate_method3. Because all ASUS WMI
evaluations will invoke  asus_wmi_evaluate_method3 at last, so all
ASUS WMI functions fail to work. I can simply fix this by extending
the bios_args from 3 args to 5 u32 args as follows, but I don't think
it's generic enough and may have to change if there're more local
variables declared in ACPI method on the future ASUS machines. Any
suggestions for this?

--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -116,6 +116,8 @@ struct bios_args {
u32 arg0;
u32 arg1;
u32 arg2; /* At least TUF Gaming series uses 3 dword input buffer. */
+   u32 arg3;
+   u32 arg4;
 } __packed;


Chris

Re: [PATCH[RFT]] ACPI: EC: s2idle: Avoid flushing EC work when EC GPE is inactive

[Chris Chiu]

On Mon, May 18, 2020 at 4:59 PM Rafael J. Wysocki  wrote:
>
> On Thu, May 14, 2020 at 12:10 PM Rafael J. Wysocki  wrote:
> >
> > From: Rafael J. Wysocki 
> >
> > Flushing the EC work while suspended to idle when the EC GPE status
> > is not set causes some EC wakeup events (notably power button and
> > lid ones) to be missed after a series of spurious wakeups on the Dell
> > XPS13 9360 in my office.
> >
> > If that happens, the machine cannot be woken up from suspend-to-idle
> > by a power button press or lid status change and it needs to be woken
> > up in some other way (eg. by a key press).
> >
> > Flushing the EC work only after successful dispatching the EC GPE,
> > which means that its status has been set, avoids the issue, so change
> > the code in question accordingly.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >
> > Hi Chris,
> >
> > Please check if the key press wakeup still works on your system with this 
> > patch
> > applied (on top of https://patchwork.kernel.org/patch/11538065/).
>
> Hi Chris,
>
> Since I haven't heard back from you and the problem at hand is a
> regression on the machine where it happens, I'm going to push this
> patch for merging.
>
> If it causes the key press wakeup issue to reappear on your machine,
> I'm afraid that we'll need to quirk it in the EC driver.
>
> Thanks!

Hi Rafael,
My laptop works w/o problem waking up from a keystroke with this patch
on top of https://patchwork.kernel.org/patch/11538065/).

Chris
>
> > ---
> >  drivers/acpi/ec.c|6 +-
> >  drivers/acpi/sleep.c |   15 ---
> >  2 files changed, 9 insertions(+), 12 deletions(-)
> >
> > Index: linux-pm/drivers/acpi/ec.c
> > ===
> > --- linux-pm.orig/drivers/acpi/ec.c
> > +++ linux-pm/drivers/acpi/ec.c
> > @@ -2020,9 +2020,13 @@ bool acpi_ec_dispatch_gpe(void)
> >  * to allow the caller to process events properly after that.
> >  */
> > ret = acpi_dispatch_gpe(NULL, first_ec->gpe);
> > -   if (ret == ACPI_INTERRUPT_HANDLED)
> > +   if (ret == ACPI_INTERRUPT_HANDLED) {
> > pm_pr_dbg("EC GPE dispatched\n");
> >
> > +   /* Flush the event and query workqueues. */
> > +   acpi_ec_flush_work();
> > +   }
> > +
> > return false;
> >  }
> >  #endif /* CONFIG_PM_SLEEP */
> > Index: linux-pm/drivers/acpi/sleep.c
> > ===
> > --- linux-pm.orig/drivers/acpi/sleep.c
> > +++ linux-pm/drivers/acpi/sleep.c
> > @@ -980,13 +980,6 @@ static int acpi_s2idle_prepare_late(void
> > return 0;
> >  }
> >
> > -static void acpi_s2idle_sync(void)
> > -{
> > -   /* The EC driver uses special workqueues that need to be flushed. */
> > -   acpi_ec_flush_work();
> > -   acpi_os_wait_events_complete(); /* synchronize Notify handling */
> > -}
> > -
> >  static bool acpi_s2idle_wake(void)
> >  {
> > if (!acpi_sci_irq_valid())
> > @@ -1018,7 +1011,7 @@ static bool acpi_s2idle_wake(void)
> > return true;
> >
> > /*
> > -* Cancel the wakeup and process all pending events in case
> > +* Cancel the SCI wakeup and process all pending events in 
> > case
> >  * there are any wakeup ones in there.
> >  *
> >  * Note that if any non-EC GPEs are active at this point, 
> > the
> > @@ -1026,8 +1019,7 @@ static bool acpi_s2idle_wake(void)
> >  * should be missed by canceling the wakeup here.
> >  */
> > pm_system_cancel_wakeup();
> > -
> > -   acpi_s2idle_sync();
> > +   acpi_os_wait_events_complete();
> >
> > /*
> >  * The SCI is in the "suspended" state now and it cannot 
> > produce
> > @@ -1060,7 +1052,8 @@ static void acpi_s2idle_restore(void)
> >  * of GPEs.
> >  */
> > acpi_os_wait_events_complete(); /* synchronize GPE processing */
> > -   acpi_s2idle_sync();
> > +   acpi_ec_flush_work(); /* flush the EC driver's workqueues */
> > +   acpi_os_wait_events_complete(); /* synchronize Notify handling */
> >
> > s2idle_wakeup = false;
> >
> >
> >
> >

Re: [PATCH[RFT]] ACPI: EC: s2idle: Avoid flushing EC work when EC GPE is inactive

[Chris Chiu]

On Mon, May 18, 2020 at 4:59 PM Rafael J. Wysocki  wrote:
>
> On Thu, May 14, 2020 at 12:10 PM Rafael J. Wysocki  wrote:
> >
> > From: Rafael J. Wysocki 
> >
> > Flushing the EC work while suspended to idle when the EC GPE status
> > is not set causes some EC wakeup events (notably power button and
> > lid ones) to be missed after a series of spurious wakeups on the Dell
> > XPS13 9360 in my office.
> >
> > If that happens, the machine cannot be woken up from suspend-to-idle
> > by a power button press or lid status change and it needs to be woken
> > up in some other way (eg. by a key press).
> >
> > Flushing the EC work only after successful dispatching the EC GPE,
> > which means that its status has been set, avoids the issue, so change
> > the code in question accordingly.
> >
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> >
> > Hi Chris,
> >
> > Please check if the key press wakeup still works on your system with this 
> > patch
> > applied (on top of https://patchwork.kernel.org/patch/11538065/).
>
> Hi Chris,
>
> Since I haven't heard back from you and the problem at hand is a
> regression on the machine where it happens, I'm going to push this
> patch for merging.
>
> If it causes the key press wakeup issue to reappear on your machine,
> I'm afraid that we'll need to quirk it in the EC driver.
>
> Thanks!
>

Sorry that I missed this email. I'll apply this patch and test again.

Re: [PATCH v2] ACPI: EC: s2idle: Avoid premature returns from acpi_s2idle_wake()

[Chris Chiu]

On Sat, May 9, 2020 at 4:44 PM Rafael J. Wysocki  wrote:
>
> From: Rafael J. Wysocki 
>
> If the EC GPE status is not set after checking all of the other GPEs,
> acpi_s2idle_wake() returns 'false', to indicate that the SCI event
> that has just triggered is not a system wakeup one, but it does that
> without canceling the pending wakeup and re-arming the SCI for system
> wakeup which is a mistake, because it may cause s2idle_loop() to busy
> spin until the next valid wakeup event.  [If that happens, the first
> spurious wakeup is still pending after acpi_s2idle_wake() has
> returned, so s2idle_enter() does nothing, acpi_s2idle_wake()
> is called again and it sees that the SCI has triggered, but no GPEs
> are active, so 'false' is returned again, and so on.]
>
> Fix that by moving all of the GPE checking logic from
> acpi_s2idle_wake() to acpi_ec_dispatch_gpe() and making the
> latter return 'true' only if a non-EC GPE has triggered and
> 'false' otherwise, which will cause acpi_s2idle_wake() to
> cancel the pending SCI wakeup and re-arm the SCI for system
> wakeup regardless of the EC GPE status.
>
> This also addresses a lockup observed on an Elitegroup EF20EA laptop
> after attempting to wake it up from suspend-to-idle by a key press.
>
> Fixes: d5406284ff80 ("ACPI: PM: s2idle: Refine active GPEs check")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=207603
> Reported-by: Todd Brandt 
> Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up 
> the system")
> Link: 
> https://lore.kernel.org/linux-acpi/CAB4CAwdqo7=mvyg_pe+pgvfea17ahf5i5jucgakqqmx6mja...@mail.gmail.com/
> Reported-by: Chris Chiu 
> Cc: 5.4+  # 5.4+
> Signed-off-by: Rafael J. Wysocki 
> ---
Tested-by: Chris Chiu 
>
> -> v2:
>* Improve the changelog and add more tags.
>
> ---
>  drivers/acpi/ec.c   |   24 
>  drivers/acpi/internal.h |1 -
>  drivers/acpi/sleep.c|   14 ++
>  3 files changed, 18 insertions(+), 21 deletions(-)
>
> Index: linux-pm/drivers/acpi/sleep.c
> ===
> --- linux-pm.orig/drivers/acpi/sleep.c
> +++ linux-pm/drivers/acpi/sleep.c
> @@ -1013,21 +1013,11 @@ static bool acpi_s2idle_wake(void)
> if (acpi_check_wakeup_handlers())
> return true;
>
> -   /*
> -* If the status bit is set for any enabled GPE other than the
> -* EC one, the wakeup is regarded as a genuine one.
> -*/
> -   if (acpi_ec_other_gpes_active())
> +   /* Check non-EC GPE wakeups and dispatch the EC GPE. */
> +   if (acpi_ec_dispatch_gpe())
> return true;
>
> /*
> -* If the EC GPE status bit has not been set, the wakeup is
> -* regarded as a spurious one.
> -*/
> -   if (!acpi_ec_dispatch_gpe())
> -   return false;
> -
> -   /*
>  * Cancel the wakeup and process all pending events in case
>  * there are any wakeup ones in there.
>  *
> Index: linux-pm/drivers/acpi/ec.c
> ===
> --- linux-pm.orig/drivers/acpi/ec.c
> +++ linux-pm/drivers/acpi/ec.c
> @@ -1994,23 +1994,31 @@ void acpi_ec_set_gpe_wake_mask(u8 action
> acpi_set_gpe_wake_mask(NULL, first_ec->gpe, action);
>  }
>
> -bool acpi_ec_other_gpes_active(void)
> -{
> -   return acpi_any_gpe_status_set(first_ec ? first_ec->gpe : U32_MAX);
> -}
> -
>  bool acpi_ec_dispatch_gpe(void)
>  {
> u32 ret;
>
> if (!first_ec)
> +   return acpi_any_gpe_status_set(U32_MAX);
> +
> +   /*
> +* Report wakeup if the status bit is set for any enabled GPE other
> +* than the EC one.
> +*/
> +   if (acpi_any_gpe_status_set(first_ec->gpe))
> +   return true;
> +
> +   if (ec_no_wakeup)
> return false;
>
> +   /*
> +* Dispatch the EC GPE in-band, but do not report wakeup in any case
> +* to allow the caller to process events properly after that.
> +*/
> ret = acpi_dispatch_gpe(NULL, first_ec->gpe);
> -   if (ret == ACPI_INTERRUPT_HANDLED) {
> +   if (ret == ACPI_INTERRUPT_HANDLED)
> pm_pr_dbg("EC GPE dispatched\n");
> -   return true;
> -   }
> +
> return false;
>  }
>  #endif /* CONFIG_PM_SLEEP */
> Index: linux-pm/drivers/acpi/internal.h
> ===
> --- linux-pm.orig/drivers/acpi/internal.h
> +++ linux-pm/drivers/acpi/internal.h
> @@ -202,7 +202,6 @@ void acpi_ec_remove_query_handler(struct
>
>  #ifdef CONFIG_PM_SLEEP
>  void acpi_ec_flush_work(void);
> -bool acpi_ec_other_gpes_active(void);
>  bool acpi_ec_dispatch_gpe(void);
>  #endif
>
>
>
>

Re: System fails to exit s2idle by a keystroke on my laptop

[Chris Chiu]

On Sat, May 9, 2020 at 12:50 AM Rafael J. Wysocki  wrote:
>
> On Friday, May 8, 2020 10:22:09 AM CEST Chris Chiu wrote:
> > On Fri, May 8, 2020 at 2:05 AM Rafael J. Wysocki  wrote:
> >
> > Ｈi Rafael,
> > Thanks for your patch. I tried it on my laptop and it's also
> > working fine. Wake up by keystroke/power button/lid open all work as
> > expected. Thanks.
>
> Thanks for the confirmation!
>
> Please also verify the final version of the patch available from
>
> https://patchwork.kernel.org/patch/11537215/
>
> Of course, it will only make a difference if the ec_no_wakeup switch is set
> on your system (either as a result of blacklisting or via the kernel command
> line).
>
> Thanks!
>
>
>

Thanks. Rafael. I've tested it on my laptop and it's still working well.

Chris

Re: System fails to exit s2idle by a keystroke on my laptop

[Chris Chiu]

On Fri, May 8, 2020 at 2:05 AM Rafael J. Wysocki  wrote:
>
> On Thursday, May 7, 2020 5:38:11 AM CEST Chris Chiu wrote:
> > On Wed, May 6, 2020 at 6:19 PM Rafael J. Wysocki  wrote:
> > >
> > > On Wed, May 6, 2020 at 11:32 AM Rafael J. Wysocki  
> > > wrote:
> > > >
> > > >
> > > > Thanks for the report, the issue evidently is EC-related.
> > > >
> > > > > @@ -1024,7 +1024,7 @@ static bool acpi_s2idle_wake(void)
> > > > >  * regarded as a spurious one.
> > > > >  */
> > > > > if (!acpi_ec_dispatch_gpe())
> > > > > -   return false;
> > > > > +   return true;
> > > >
> > > > Have you tried commenting out simply removing the if () check and the
> > > > following return statement?
> > >
> > > Scratch that.
> > >
> > > Instead, please try doing
> > >
> > > acpi_ec_dispatch_gpe()
> > >
> > > instead of the if () and the following return statement.
> >
> > Yes. I verified with the modification you suggested on my laptop. It's
> > working OK.
> > I can wake from a keystroke w/o problem.
> >
> > @ -1024,8 +1024,7 @@ static bool acpi_s2idle_wake(void)
> >  * If the EC GPE status bit has not been set, the wakeup is
> >  * regarded as a spurious one.
> >  */
> > -   if (!acpi_ec_dispatch_gpe())
> > -   return false;
> > +   acpi_ec_dispatch_gpe();
> >
> > /*
> >  * Cancel the wakeup and process all pending events in case
> >
>
> OK, great, thanks for the confirmation!
>
> Does the appended patch work for you then?
>
> It should be functionally equivalent to the above change if I didn't mess it 
> up.
>
>
> ---
>  drivers/acpi/ec.c   |   23 ++-
>  drivers/acpi/internal.h |1 -
>  drivers/acpi/sleep.c|   14 ++
>  3 files changed, 16 insertions(+), 22 deletions(-)
>
> Index: linux-pm/drivers/acpi/sleep.c
> ===
> --- linux-pm.orig/drivers/acpi/sleep.c
> +++ linux-pm/drivers/acpi/sleep.c
> @@ -1013,21 +1013,11 @@ static bool acpi_s2idle_wake(void)
> if (acpi_check_wakeup_handlers())
> return true;
>
> -   /*
> -* If the status bit is set for any enabled GPE other than the
> -* EC one, the wakeup is regarded as a genuine one.
> -*/
> -   if (acpi_ec_other_gpes_active())
> +   /* Check non-EC GPE wakeups and dispatch the EC GPE. */
> +   if (acpi_ec_dispatch_gpe())
> return true;
>
> /*
> -* If the EC GPE status bit has not been set, the wakeup is
> -* regarded as a spurious one.
> -*/
> -   if (!acpi_ec_dispatch_gpe())
> -   return false;
> -
> -   /*
>  * Cancel the wakeup and process all pending events in case
>  * there are any wakeup ones in there.
>  *
> Index: linux-pm/drivers/acpi/ec.c
> ===
> --- linux-pm.orig/drivers/acpi/ec.c
> +++ linux-pm/drivers/acpi/ec.c
> @@ -1994,23 +1994,28 @@ void acpi_ec_set_gpe_wake_mask(u8 action
> acpi_set_gpe_wake_mask(NULL, first_ec->gpe, action);
>  }
>
> -bool acpi_ec_other_gpes_active(void)
> -{
> -   return acpi_any_gpe_status_set(first_ec ? first_ec->gpe : U32_MAX);
> -}
> -
>  bool acpi_ec_dispatch_gpe(void)
>  {
> u32 ret;
>
> if (!first_ec)
> -   return false;
> +   return acpi_any_gpe_status_set(U32_MAX);
>
> +   /*
> +* Report wakeup if the status bit is set for any enabled GPE other
> +* than the EC one.
> +*/
> +   if (acpi_any_gpe_status_set(first_ec->gpe))
> +   return true;
> +
> +   /*
> +* Dispatch the EC GPE in-band, but do not report wakeup in any case
> +* to allow the caller to process events properly after that.
> +*/
> ret = acpi_dispatch_gpe(NULL, first_ec->gpe);
> -   if (ret == ACPI_INTERRUPT_HANDLED) {
> +   if (ret == ACPI_INTERRUPT_HANDLED)
> pm_pr_dbg("EC GPE dispatched\n");
>

Re: System fails to exit s2idle by a keystroke on my laptop

[Chris Chiu]

On Wed, May 6, 2020 at 6:19 PM Rafael J. Wysocki  wrote:
>
> On Wed, May 6, 2020 at 11:32 AM Rafael J. Wysocki  wrote:
> >
> >
> > Thanks for the report, the issue evidently is EC-related.
> >
> > > @@ -1024,7 +1024,7 @@ static bool acpi_s2idle_wake(void)
> > >  * regarded as a spurious one.
> > >  */
> > > if (!acpi_ec_dispatch_gpe())
> > > -   return false;
> > > +   return true;
> >
> > Have you tried commenting out simply removing the if () check and the
> > following return statement?
>
> Scratch that.
>
> Instead, please try doing
>
> acpi_ec_dispatch_gpe()
>
> instead of the if () and the following return statement.

Yes. I verified with the modification you suggested on my laptop. It's
working OK.
I can wake from a keystroke w/o problem.

@ -1024,8 +1024,7 @@ static bool acpi_s2idle_wake(void)
 * If the EC GPE status bit has not been set, the wakeup is
 * regarded as a spurious one.
 */
-   if (!acpi_ec_dispatch_gpe())
-   return false;
+   acpi_ec_dispatch_gpe();

/*
 * Cancel the wakeup and process all pending events in case

System fails to exit s2idle by a keystroke on my laptop

[Chris Chiu]

Hi,
I have an Intel X5-Z8350 laptop which used to work fine on s2idle
enter/exit with kernel 5.3. After upgrading to kernel 5.4 and later,
the system can still exit s2idle by power button. However, if I try to
wake it up from a keystroke, the system will freeze and then no longer
respond even to the power button. I can only shut it down and power on
again.

I tried to 'git bisect' to find out which commit causes the
difference, it shows me the commit "ACPI: PM: s2idle: Prevent spurious
SCIs from waking up the system". My laptop can work as usual to exit
s2idle by a keystroke with reverting it on kernel 5.4.

Then I tried to check whether I can reproduce it on the latest
mainline kernel, the same problem still there. But I can not fix it by
simply reverting. I found the acpi_s2idle_wake() has been refined on
the latest mainline kernel, and I have to make modifications as
follows to make my laptop work.

@@ -1024,7 +1024,7 @@ static bool acpi_s2idle_wake(void)
 * regarded as a spurious one.
 */
if (!acpi_ec_dispatch_gpe())
-   return false;
+   return true;

/*
 * Cancel the wakeup and process all pending events in case

Maybe there's something special on my laptop so a keystroke is
considered as a spurious event on this machine? Don't know if the DSDT
helps or not.
https://gist.github.com/mschiu77/de8af6da78be12cf442853e7747f76ed

Please let me know if there's anything I can help to address this
problem. Thanks

Chris

[PATCH] rtl8xxxu: fix warnings for symbol not declared.

[Chris Chiu]

Fix the following sparse warnings.
sparse: symbol 'rtl8723bu_set_coex_with_type' was not declared.
Should it be static?
sparse: symbol 'rtl8723bu_update_bt_link_info' was not declared.
Should it be static?
sparse: symbol 'rtl8723bu_handle_bt_inquiry' was not declared.
Should it be static?
sparse: symbol 'rtl8723bu_handle_bt_info' was not declared.
Should it be static?

Signed-off-by: Chris Chiu 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index f982f91b8bb6..eac91690772b 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5194,6 +5194,7 @@ static void rtl8xxxu_rx_urb_work(struct work_struct *work)
  * cases which Realtek doesn't provide detail for these settings. Keep
  * this aligned with vendor driver for easier maintenance.
  */
+static
 void rtl8723bu_set_coex_with_type(struct rtl8xxxu_priv *priv, u8 type)
 {
switch (type) {
@@ -5245,6 +5246,7 @@ void rtl8723bu_set_coex_with_type(struct rtl8xxxu_priv 
*priv, u8 type)
}
 }
 
+static
 void rtl8723bu_update_bt_link_info(struct rtl8xxxu_priv *priv, u8 bt_info)
 {
struct rtl8xxxu_btcoex *btcoex = >bt_coex;
@@ -5311,6 +5313,7 @@ void rtl8723bu_update_bt_link_info(struct rtl8xxxu_priv 
*priv, u8 bt_info)
btcoex->bt_busy = false;
 }
 
+static
 void rtl8723bu_handle_bt_inquiry(struct rtl8xxxu_priv *priv)
 {
struct ieee80211_vif *vif;
@@ -5336,6 +5339,7 @@ void rtl8723bu_handle_bt_inquiry(struct rtl8xxxu_priv 
*priv)
}
 }
 
+static
 void rtl8723bu_handle_bt_info(struct rtl8xxxu_priv *priv)
 {
struct ieee80211_vif *vif;
-- 
2.20.1

Re: [PATCH] rtl8xxxu: remove set but not used variable 'rate_mask'

[Chris Chiu]

On Wed, Oct 23, 2019 at 3:54 PM YueHaibing  wrote:
>
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:4484:6:
>  warning: variable rate_mask set but not used [-Wunused-but-set-variable]
>
> It is never used since commit a9bb0b515778 ("rtl8xxxu: Improve
> TX performance of RTL8723BU on rtl8xxxu driver")
>
> Signed-off-by: YueHaibing 
> ---
Singed-off-by: Chris Chiu 

>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 1e3b716..3843d7a 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -4481,11 +4481,6 @@ static u16
>  rtl8xxxu_wireless_mode(struct ieee80211_hw *hw, struct ieee80211_sta *sta)
>  {
> u16 network_type = WIRELESS_MODE_UNKNOWN;
> -   u32 rate_mask;
> -
> -   rate_mask = (sta->supp_rates[0] & 0xfff) |
> -   (sta->ht_cap.mcs.rx_mask[0] << 12) |
> -   (sta->ht_cap.mcs.rx_mask[0] << 20);
>
> if (hw->conf.chandef.chan->band == NL80211_BAND_5GHZ) {
> if (sta->vht_cap.vht_supported)
> --
> 2.7.4

Thanks for pointing that out.

Chris

Re: [PATCH v2] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

[Chris Chiu]

On Thu, Oct 17, 2019 at 10:26 AM Chris Chiu  wrote:
>
> On Wed, Oct 16, 2019 at 9:54 AM Chris Chiu  wrote:
> >
> > The RTL8723BU has problems connecting to AP after each warm reboot.
> > Sometimes it returns no scan result, and in most cases, it fails
> > the authentication for unknown reason. However, it works totally
> > fine after cold reboot.
> >
> > Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
> > for cold reboot and warm reboot, the registers imply that the MAC
> > is already powered and thus some procedures are skipped during
> > driver initialization. Double checked the vendor driver, it reads
> > the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
> > during initialization based on them. This commit only tells the
> > RTL8723BU to do full initialization without checking MAC status.
> >
> > Signed-off-by: Chris Chiu 
> Signed-off-by: Jes Sorensen 
>
> Sorry, I forgot to add Jes.
>
> Chris
> > ---
> >
> > Note:
> >   v2: fix typo of commit message
> >
> >

Gentle ping. Cheers.

Chris

Re: [PATCH v2] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

[Chris Chiu]

On Wed, Oct 16, 2019 at 9:54 AM Chris Chiu  wrote:
>
> The RTL8723BU has problems connecting to AP after each warm reboot.
> Sometimes it returns no scan result, and in most cases, it fails
> the authentication for unknown reason. However, it works totally
> fine after cold reboot.
>
> Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
> for cold reboot and warm reboot, the registers imply that the MAC
> is already powered and thus some procedures are skipped during
> driver initialization. Double checked the vendor driver, it reads
> the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
> during initialization based on them. This commit only tells the
> RTL8723BU to do full initialization without checking MAC status.
>
> Signed-off-by: Chris Chiu 
Signed-off-by: Jes Sorensen 

Sorry, I forgot to add Jes.

Chris
> ---
>
> Note:
>   v2: fix typo of commit message
>
>

[PATCH v2] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

[Chris Chiu]

The RTL8723BU has problems connecting to AP after each warm reboot.
Sometimes it returns no scan result, and in most cases, it fails
the authentication for unknown reason. However, it works totally
fine after cold reboot.

Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
for cold reboot and warm reboot, the registers imply that the MAC
is already powered and thus some procedures are skipped during
driver initialization. Double checked the vendor driver, it reads
the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
during initialization based on them. This commit only tells the
RTL8723BU to do full initialization without checking MAC status.

Signed-off-by: Chris Chiu 
---

Note:
  v2: fix typo of commit message


 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 22e95b11bfbb..6598c8d786ea 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1425,6 +1425,7 @@ struct rtl8xxxu_fileops {
u8 has_s0s1:1;
u8 has_tx_report:1;
u8 gen2_thermal_meter:1;
+   u8 needs_full_init:1;
u32 adda_1t_init;
u32 adda_1t_path_on;
u32 adda_2t_path_on_a;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 9ba661b3d767..a1c3787abe2e 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1668,6 +1668,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
.has_s0s1 = 1,
.has_tx_report = 1,
.gen2_thermal_meter = 1,
+   .needs_full_init = 1,
.adda_1t_init = 0x01c00014,
.adda_1t_path_on = 0x01c00014,
.adda_2t_path_on_a = 0x01c00014,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index e4c1b08c8070..8420cb269b8d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3900,6 +3900,9 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
else
macpower = true;
 
+   if (fops->needs_full_init)
+   macpower = false;
+
ret = fops->power_on(priv);
if (ret < 0) {
dev_warn(dev, "%s: Failed power on\n", __func__);
-- 
2.23.0

Re: [PATCH] rtl8xxxu: fix connection failure issue after warm reboot

[Chris Chiu]

On Tue, Oct 15, 2019 at 6:16 PM Chris Chiu  wrote:
>
> ---
> 2.23.0
>
Please ignore this message since it's not properly titled and no
detail description.
Sorry for inconvenience.

Chris

[PATCH] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

[Chris Chiu]

The RTL8723BU has problems connecting to AP after each warm reboot.
Sometimes it returns no scan result, and in most cases, it fails
the authentication for unknown reason. However, it works totally
fine after cold reboot.

Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
for cold reboot and warm reboot, the registers imply that the MAC
is already powered and thus some procedures are skipped during
driver initialization. Double checked the vendor driver, it reads
the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
during initialization based on them. This commit only tells the
RTL8723BU to do full initialization without checking MAC status.

https://phabricator.endlessm.com/T28000

Signed-off-by: Chris Chiu 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 22e95b11bfbb..6598c8d786ea 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1425,6 +1425,7 @@ struct rtl8xxxu_fileops {
u8 has_s0s1:1;
u8 has_tx_report:1;
u8 gen2_thermal_meter:1;
+   u8 needs_full_init:1;
u32 adda_1t_init;
u32 adda_1t_path_on;
u32 adda_2t_path_on_a;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 9ba661b3d767..a1c3787abe2e 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1668,6 +1668,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
.has_s0s1 = 1,
.has_tx_report = 1,
.gen2_thermal_meter = 1,
+   .needs_full_init = 1,
.adda_1t_init = 0x01c00014,
.adda_1t_path_on = 0x01c00014,
.adda_2t_path_on_a = 0x01c00014,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index e4c1b08c8070..8420cb269b8d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3900,6 +3900,9 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
else
macpower = true;
 
+   if (fops->needs_full_init)
+   macpower = false;
+
ret = fops->power_on(priv);
if (ret < 0) {
dev_warn(dev, "%s: Failed power on\n", __func__);
-- 
2.23.0

[PATCH] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

[Chris Chiu]

The RTL8723BU has problems connecting to AP after each warm reboot.
Sometimes it returns no scan result, and in most cases, it fails
the authentication for unknown reason. However, it works totally
fine after cold reboot.

Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
for cold reboot and warm reboot, the registers imply that the MAC
is already powered and thus some procedures are skipped during
driver initialization. Double checked the vendor driver, it reads
the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
during initialization based on them. This commit only tells the
RTL8723BU to do full initilization without checking MAC status.

Signed-off-by: Chris Chiu 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 22e95b11bfbb..6598c8d786ea 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1425,6 +1425,7 @@ struct rtl8xxxu_fileops {
u8 has_s0s1:1;
u8 has_tx_report:1;
u8 gen2_thermal_meter:1;
+   u8 needs_full_init:1;
u32 adda_1t_init;
u32 adda_1t_path_on;
u32 adda_2t_path_on_a;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 9ba661b3d767..a1c3787abe2e 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1668,6 +1668,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
.has_s0s1 = 1,
.has_tx_report = 1,
.gen2_thermal_meter = 1,
+   .needs_full_init = 1,
.adda_1t_init = 0x01c00014,
.adda_1t_path_on = 0x01c00014,
.adda_2t_path_on_a = 0x01c00014,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index e4c1b08c8070..8420cb269b8d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3900,6 +3900,9 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
else
macpower = true;
 
+   if (fops->needs_full_init)
+   macpower = false;
+
ret = fops->power_on(priv);
if (ret < 0) {
dev_warn(dev, "%s: Failed power on\n", __func__);
-- 
2.23.0

[PATCH] rtl8xxxu: fix connection failure issue after warm reboot

[Chris Chiu]

---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 1 +
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 22e95b11bfbb..fd2ad7d07335 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1425,6 +1425,7 @@ struct rtl8xxxu_fileops {
u8 has_s0s1:1;
u8 has_tx_report:1;
u8 gen2_thermal_meter:1;
+u8 needs_full_init:1;
u32 adda_1t_init;
u32 adda_1t_path_on;
u32 adda_2t_path_on_a;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 9ba661b3d767..fef1a91489a5 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1668,6 +1668,7 @@ struct rtl8xxxu_fileops rtl8723bu_fops = {
.has_s0s1 = 1,
.has_tx_report = 1,
.gen2_thermal_meter = 1,
+.needs_full_init = 1,
.adda_1t_init = 0x01c00014,
.adda_1t_path_on = 0x01c00014,
.adda_2t_path_on_a = 0x01c00014,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index e4c1b08c8070..8420cb269b8d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3900,6 +3900,9 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
else
macpower = true;
 
+   if (fops->needs_full_init)
+   macpower = false;
+
ret = fops->power_on(priv);
if (ret < 0) {
dev_warn(dev, "%s: Failed power on\n", __func__);
-- 
2.23.0

Re: [PATCH v8] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

[Chris Chiu]

On Wed, Oct 2, 2019 at 8:18 PM Chris Chiu  wrote:

>   v7:
>- Fix reported bug of watchdog stop
>- refer to the RxPWDBAll in vendor driver for SNR calculation
>   v8:
>- Add missing break in switch case
>
> +   case WIRELESS_MODE_N_24G:
> +   case WIRELESS_MODE_N_5G:
> +   case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
> +   case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G):
> +   if (priv->tx_paths == 2 && priv->rx_paths == 2)
> +   ratr_idx = RATEID_IDX_GN_N2SS;
> +   else
> +   ratr_idx = RATEID_IDX_GN_N1SS;
> +   break;

Hi,
I have fixed the missing break problem in v7. Please let me know if there is
any problem. Thanks.

Chris

Re: [PATCH] rtl8xxxu: make arrays static, makes object smaller

[Chris Chiu]

On Mon, Oct 7, 2019 at 9:53 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> Don't populate const arrays on the stack but instead make them
> static. Makes the object code smaller by 60 bytes.
>
> Before:
>textdata bss dec hex filename
>   151338768   0   239015d5d realtek/rtl8xxxu/rtl8xxxu_8192e.o
>   152096392   0   216015461 realtek/rtl8xxxu/rtl8xxxu_8723b.o
>  103254   31202 576  135032   20f78 realtek/rtl8xxxu/rtl8xxxu_core.o
>
> After:
>textdata bss dec hex filename
>   148619024   0   238855d4d realtek/rtl8xxxu/rtl8xxxu_8192e.o
>   149536616   0   215695441 realtek/rtl8xxxu/rtl8xxxu_8723b.o
>  102986   31458 576  135020   20f6c realtek/rtl8xxxu/rtl8xxxu_core.o
>
> (gcc version 9.2.1, amd64)
>
> Signed-off-by: Colin Ian King 
> ---
Reviewed-by: Chris Chiu 

[PATCH v3] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

The RTL8723BU suffers the wifi disconnection problem while bluetooth
device connected. While wifi is doing tx/rx, the bluetooth will scan
without results. This is due to the wifi and bluetooth share the same
single antenna for RF communication and they need to have a mechanism
to collaborate.

BT information is provided via the packet sent from co-processor to
host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h
dose not really handle it. And there's no bluetooth coexistence
mechanism to deal with it.

This commit adds a workqueue to set the tdma configurations and
coefficient table per the parsed bluetooth link status and given
wifi connection state. The tdma/coef table comes from the vendor
driver code of the RTL8192EU and RTL8723BU. However, this commit is
only for single antenna scenario which RTL8192EU is default dual
antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h
is only for 8723b and 8192e so the mechanism is expected to work
on both chips with single antenna. Note RTL8192EU dual antenna is
not supported.

Signed-off-by: Chris Chiu 
---

Notes:
  v2:
   - Add helper functions to replace bunch of tdma settings
   - Reformat some lines to meet kernel coding style
  v3:
   - Add comment for rtl8723bu_set_coex_with_type()


 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h  |  37 +++
 .../realtek/rtl8xxxu/rtl8xxxu_8723b.c |   2 -
 .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 269 +-
 3 files changed, 301 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 582c2a346cec..22e95b11bfbb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1220,6 +1220,37 @@ enum ratr_table_mode_new {
RATEID_IDX_BGN_3SS = 14,
 };
 
+#define BT_INFO_8723B_1ANT_B_FTP   BIT(7)
+#define BT_INFO_8723B_1ANT_B_A2DP  BIT(6)
+#define BT_INFO_8723B_1ANT_B_HID   BIT(5)
+#define BT_INFO_8723B_1ANT_B_SCO_BUSY  BIT(4)
+#define BT_INFO_8723B_1ANT_B_ACL_BUSY  BIT(3)
+#define BT_INFO_8723B_1ANT_B_INQ_PAGE  BIT(2)
+#define BT_INFO_8723B_1ANT_B_SCO_ESCO  BIT(1)
+#define BT_INFO_8723B_1ANT_B_CONNECTIONBIT(0)
+
+enum _BT_8723B_1ANT_STATUS {
+   BT_8723B_1ANT_STATUS_NON_CONNECTED_IDLE  = 0x0,
+   BT_8723B_1ANT_STATUS_CONNECTED_IDLE  = 0x1,
+   BT_8723B_1ANT_STATUS_INQ_PAGE= 0x2,
+   BT_8723B_1ANT_STATUS_ACL_BUSY= 0x3,
+   BT_8723B_1ANT_STATUS_SCO_BUSY= 0x4,
+   BT_8723B_1ANT_STATUS_ACL_SCO_BUSY= 0x5,
+   BT_8723B_1ANT_STATUS_MAX
+};
+
+struct rtl8xxxu_btcoex {
+   u8  bt_status;
+   boolbt_busy;
+   boolhas_sco;
+   boolhas_a2dp;
+   boolhas_hid;
+   boolhas_pan;
+   boolhid_only;
+   boola2dp_only;
+   boolc2h_bt_inquiry;
+};
+
 #define RTL8XXXU_RATR_STA_INIT 0
 #define RTL8XXXU_RATR_STA_HIGH 1
 #define RTL8XXXU_RATR_STA_MID  2
@@ -1340,6 +1371,10 @@ struct rtl8xxxu_priv {
 */
struct ieee80211_vif *vif;
struct delayed_work ra_watchdog;
+   struct work_struct c2hcmd_work;
+   struct sk_buff_head c2hcmd_queue;
+   spinlock_t c2hcmd_lock;
+   struct rtl8xxxu_btcoex bt_coex;
 };
 
 struct rtl8xxxu_rx_urb {
@@ -1486,6 +1521,8 @@ void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, 
struct ieee80211_hdr *hdr,
 struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
 bool short_preamble, bool ampdu_enable,
 u32 rts_rate);
+void rtl8723bu_set_ps_tdma(struct rtl8xxxu_priv *priv,
+  u8 arg1, u8 arg2, u8 arg3, u8 arg4, u8 arg5);
 
 extern struct rtl8xxxu_fileops rtl8192cu_fops;
 extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index ceffe05bd65b..9ba661b3d767 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1580,9 +1580,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
/*
 * Software control, antenna at WiFi side
 */
-#ifdef NEED_PS_TDMA
rtl8723bu_set_ps_tdma(priv, 0x08, 0x00, 0x00, 0x00, 0x00);
-#endif
 
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE1, 0x);
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE2, 0x);
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index bd5ccb3aa5d7..8c47fdf2fdef 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3820,9 +3820,8 @@ void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv

Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

On Wed, Oct 2, 2019 at 11:04 PM Jes Sorensen  wrote:
>
>
> In general I think it looks good! One nit below:
>
> Sorry I have been traveling for the last three weeks, so just catching up.
>
>
> > +void rtl8723bu_set_coex_with_type(struct rtl8xxxu_priv *priv, u8 type)
> > +{
> > + switch (type) {
> > + case 0:
> > + rtl8xxxu_write32(priv, REG_BT_COEX_TABLE1, 0x);
> > + rtl8xxxu_write32(priv, REG_BT_COEX_TABLE2, 0x);
> > + rtl8xxxu_write32(priv, REG_BT_COEX_TABLE3, 0x00ff);
> > + rtl8xxxu_write8(priv, REG_BT_COEX_TABLE4, 0x03);
> > + break;
> > + case 1:
> > + case 3:
>
> The one item here, I would prefer introducing some defined types to
> avoid the hard coded type numbers. It's much easier to read and debug
> when named.
>
Honestly, I also thought of that but there's no meaningful description for these
numbers in the vendor driver. Even based on where they're invoked, I can merely
give a rough definition on 0. So I left it as it is for the covenience
if I have to do
cross-comparison with vendor driver in the future for some possible
unknown bugs.

> If you shortened the name of the function to rtl8723bu_set_coex() you
> won't have problems with line lengths at the calling point.
>
I think the rtl8723bu_set_ps_tdma() function would cause the line length problem
more than rtl8723bu_set_coex_with_type() at the calling point. But as the same
debug reason as mentioned, I may like to keep it because I don't know how to
categorize the 5 magic parameters. I also reference the latest rtw88
driver code,
it seems no better solution so far. I'll keep watching if there's any
better idea.

Chris

Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

On Wed, Oct 2, 2019 at 12:29 PM Kalle Valo  wrote:

> Failed to apply, please rebase on top of wireless-drivers-next.
>
> fatal: sha1 information is lacking or useless 
> (drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h).
> error: could not build fake ancestor
> Applying: rtl8xxxu: add bluetooth co-existence support for single antenna
> Patch failed at 0001 rtl8xxxu: add bluetooth co-existence support for single 
> antenna
> The copy of the patch that failed is found in: .git/rebase-apply/patch
>
> Patch set to Changes Requested.
>
> --
> https://patchwork.kernel.org/patch/11140223/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

The failure is because this patch needs the 'enum wireless_mode' from another
patch https://patchwork.kernel.org/patch/11148163/ which I already submit the
new v8 version. I didn't put them in the same series due to it really
took me a long
time to come out after tx performance improvement patch upstream. Please apply
this one after 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2117331.html.
Thanks.

Chris

Re: [PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

[Chris Chiu]

On Wed, Oct 2, 2019 at 12:30 PM Kalle Valo  wrote:
> New warning:
>
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function 
> 'rtl8xxxu_refresh_rate_mask':
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5907:7: warning: this 
> statement may fall through [-Wimplicit-fallthrough=]
> if (priv->tx_paths == 2 && priv->rx_paths == 2)
>^
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5911:3: note: here
>case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G):
>^~~~
>
> Patch set to Changes Requested.
>
> --
> https://patchwork.kernel.org/patch/11148163/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

Thanks for pointing this out, I've sent a v8 version to fix it.

Chris

[PATCH v8] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

[Chris Chiu]

We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.

After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.

With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.

Signed-off-by: Chris Chiu 
Reviewed-by: Daniel Drake 
Acked-by: Jes Sorensen 
---


Notes:
  v2:
   - Fix errors and warnings complained by checkpatch.pl
   - Replace data structure rate_adaptive by 2 member variables
   - Make rtl8xxxu_wireless_mode non-static
   - Runs refresh_rate_mask() only in station mode
  v3:
   - Remove ugly rtl8xxxu_watchdog data structure
   - Make sure only one vif exists
  v4:
   - Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
   - Clear priv->vif in rtl8xxxu_remove_interface
   - Add rateid as the function argument of update_rate_mask
   - Rephrase the comment for priv->vif more explicit.
  v5:
   - Make refresh_rate_mask() generic for all sub-drivers.
   - Add definitions for SNR related to help determine rssi_level
  v6:
   - Fix typo of the comment for priv->vif
  v7:
   - Fix reported bug of watchdog stop
   - refer to the RxPWDBAll in vendor driver for SNR calculation
  v8:
   - Add missing break in switch case


 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h  |  55 -
 .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 230 +-
 2 files changed, 278 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index ade057d868f7..582c2a346cec 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
 
 struct rtl8xxxu_fileops;
 
+/*mlme related.*/
+enum wireless_mode {
+   WIRELESS_MODE_UNKNOWN = 0,
+   /* Sub-Element */
+   WIRELESS_MODE_B = BIT(0),
+   WIRELESS_MODE_G = BIT(1),
+   WIRELESS_MODE_A = BIT(2),
+   WIRELESS_MODE_N_24G = BIT(3),
+   WIRELESS_MODE_N_5G = BIT(4),
+   WIRELESS_AUTO = BIT(5),
+   WIRELESS_MODE_AC = BIT(6),
+   WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+   RATEID_IDX_BGN_40M_2SS = 0,
+   RATEID_IDX_BGN_40M_1SS = 1,
+   RATEID_IDX_BGN_20M_2SS_BN = 2,
+   RATEID_IDX_BGN_20M_1SS_BN = 3,
+   RATEID_IDX_GN_N2SS = 4,
+   RATEID_IDX_GN_N1SS = 5,
+   RATEID_IDX_BG = 6,
+   RATEID_IDX_G = 7,
+   RATEID_IDX_B = 8,
+   RATEID_IDX_VHT_2SS = 9,
+   RATEID_IDX_VHT_1SS = 10,
+   RATEID_IDX_MIX1 = 11,
+   RATEID_IDX_MIX2 = 12,
+   RATEID_IDX_VHT_3SS = 13,
+   RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID  2
+#define RTL8XXXU_RATR_STA_LOW  3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN   -100
+#define RTL8XXXU_SNR_THRESH_HIGH   50
+#define RTL8XXXU_SNR_THRESH_LOW20
+
 struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1291,6 +1333,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+   u8 rssi_level;
+   /*
+* Only one virtual interface permitted because only STA mode
+* is supported and no iface_combinations are provided.
+*/
+   struct ieee80211_vif *vif;
+   struct del

Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

On Thu, Sep 19, 2019 at 9:44 AM Chris Chiu  wrote:
>
> On Wed, Sep 11, 2019 at 10:50 AM Chris Chiu  wrote:
> >
> >
> > Notes:
> >   v2:
> >- Add helper functions to replace bunch of tdma settings
> >- Reformat some lines to meet kernel coding style
> >
> >
>
Hi Jes,
I've refactored the code per your suggestion. Any comment for further
improvement? Thanks.

Chris

Re: [PATCH] rtl8xxxu: prevent leaking urb

[Chris Chiu]

On Fri, Sep 20, 2019 at 11:01 AM Navid Emamdoost
 wrote:
>
> In rtl8xxxu_submit_int_urb if usb_submit_urb fails the allocated urb
> should be released.
>
> Signed-off-by: Navid Emamdoost 
Reviewed-by: Chris Chiu 


> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -5443,6 +5443,7 @@ static int rtl8xxxu_submit_int_urb(struct ieee80211_hw 
> *hw)
> ret = usb_submit_urb(urb, GFP_KERNEL);
> if (ret) {
> usb_unanchor_urb(urb);
> +   usb_free_urb(urb);
> goto error;
> }
You're right. There's a usb_alloc_urb in the beginning of this
function and should be
handled after submit failure.

Chris

Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

On Wed, Sep 11, 2019 at 10:50 AM Chris Chiu  wrote:
>
>
> Notes:
>   v2:
>- Add helper functions to replace bunch of tdma settings
>- Reformat some lines to meet kernel coding style
>
>

Gentle ping. Any suggestions would be appreciated. Thanks.

Chris

[PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

[Chris Chiu]

We have 3 laptops which connect the wifi by the same RTL8723BU.
The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
They have the same problem with the in-kernel rtl8xxxu driver, the
iperf (as a client to an ethernet-connected server) gets ~1Mbps.
Nevertheless, the signal strength is reported as around -40dBm,
which is quite good. From the wireshark capture, the tx rate for each
data and qos data packet is only 1Mbps. Compare to the Realtek driver
at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
~12Mbps or better. The signal strength is reported similarly around
-40dBm. That's why we want to improve.

After reading the source code of the rtl8xxxu driver and Realtek's, the
major difference is that Realtek's driver has a watchdog which will keep
monitoring the signal quality and updating the rate mask just like the
rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
And this kind of watchdog also exists in rtlwifi driver of some specific
chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
the same member function named dm_watchdog and will invoke the
corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
mask.

With this commit, the tx rate of each data and qos data packet will
be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit
to 23th bit means MCS4 to MCS7. It means that the firmware still picks
the lowest rate from the rate mask and explains why the tx rate of
data and qos data is always lowest 1Mbps because the default rate mask
passed is always 0xFFF ranges from the basic CCK rate, OFDM rate,
and MCS rate. However, with Realtek's driver, the tx rate observed from
wireshark under the same condition is almost 65Mbps or 72Mbps, which
indicating that rtl8xxxu could still be further improved.

Signed-off-by: Chris Chiu 
Reviewed-by: Daniel Drake 
---


Notes:
  v2:
   - Fix errors and warnings complained by checkpatch.pl
   - Replace data structure rate_adaptive by 2 member variables
   - Make rtl8xxxu_wireless_mode non-static
   - Runs refresh_rate_mask() only in station mode
  v3:
   - Remove ugly rtl8xxxu_watchdog data structure
   - Make sure only one vif exists
  v4:
   - Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
   - Clear priv->vif in rtl8xxxu_remove_interface
   - Add rateid as the function argument of update_rate_mask
   - Rephrase the comment for priv->vif more explicit.
  v5:
   - Make refresh_rate_mask() generic for all sub-drivers.
   - Add definitions for SNR related to help determine rssi_level
  v6: 
   - Fix typo of the comment for priv->vif
  v7:
   - Fix reported bug of watchdog stop 
   - refer to the RxPWDBAll in vendor driver for SNR calculation


 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h  |  55 -
 .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 229 +-
 2 files changed, 277 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index ade057d868f7..582c2a346cec 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
 
 struct rtl8xxxu_fileops;
 
+/*mlme related.*/
+enum wireless_mode {
+   WIRELESS_MODE_UNKNOWN = 0,
+   /* Sub-Element */
+   WIRELESS_MODE_B = BIT(0),
+   WIRELESS_MODE_G = BIT(1),
+   WIRELESS_MODE_A = BIT(2),
+   WIRELESS_MODE_N_24G = BIT(3),
+   WIRELESS_MODE_N_5G = BIT(4),
+   WIRELESS_AUTO = BIT(5),
+   WIRELESS_MODE_AC = BIT(6),
+   WIRELESS_MODE_MAX = 0x7F,
+};
+
+/* from rtlwifi/wifi.h */
+enum ratr_table_mode_new {
+   RATEID_IDX_BGN_40M_2SS = 0,
+   RATEID_IDX_BGN_40M_1SS = 1,
+   RATEID_IDX_BGN_20M_2SS_BN = 2,
+   RATEID_IDX_BGN_20M_1SS_BN = 3,
+   RATEID_IDX_GN_N2SS = 4,
+   RATEID_IDX_GN_N1SS = 5,
+   RATEID_IDX_BG = 6,
+   RATEID_IDX_G = 7,
+   RATEID_IDX_B = 8,
+   RATEID_IDX_VHT_2SS = 9,
+   RATEID_IDX_VHT_1SS = 10,
+   RATEID_IDX_MIX1 = 11,
+   RATEID_IDX_MIX2 = 12,
+   RATEID_IDX_VHT_3SS = 13,
+   RATEID_IDX_BGN_3SS = 14,
+};
+
+#define RTL8XXXU_RATR_STA_INIT 0
+#define RTL8XXXU_RATR_STA_HIGH 1
+#define RTL8XXXU_RATR_STA_MID  2
+#define RTL8XXXU_RATR_STA_LOW  3
+
+#define RTL8XXXU_NOISE_FLOOR_MIN   -100
+#define RTL8XXXU_SNR_THRESH_HIGH   50
+#define RTL8XXXU_SNR_THRESH_LOW20
+
 struct rtl8xxxu_priv {
struct ieee80211_hw *hw;
struct usb_device *udev;
@@ -1291,6 +1333,13 @@ struct rtl8xxxu_priv {
u8 pi_enabled:1;
u8 no_pape:1;
u8 int_buf[USB_INTR_CONTENT_LENGTH];
+   u8 rssi_level;
+   /*
+* Only one virtual interface permitted because only STA mode
+* is supported and no iface_combinations are provided.
+*/
+   struct ieee80211_vif *vif;
+   struct delayed_work ra_watchdog;
 };
 
 struct rtl8xxxu_rx_urb {
@@ -1326,

Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

[Chris Chiu]

On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen  wrote:
>
> On 8/12/19 10:32 AM, Kalle Valo wrote:
> >> Signed-off-by: Jes Sorensen 
> >
> > This is marked as RFC so I'm not sure what's the plan. Should I apply
> > this?
>
> I think it's at a point where it's worth applying - I kinda wish I had
> had time to test it, but I won't be near my stash of USB dongles for a
> little while.
>
> Cheers,
> Jes
>

Gentle ping. Any suggestions for the next step?

Chris

[PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

The RTL8723BU suffers the wifi disconnection problem while bluetooth
device connected. While wifi is doing tx/rx, the bluetooth will scan
without results. This is due to the wifi and bluetooth share the same
single antenna for RF communication and they need to have a mechanism
to collaborate.

BT information is provided via the packet sent from co-processor to
host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h
dose not really handle it. And there's no bluetooth coexistence
mechanism to deal with it.

This commit adds a workqueue to set the tdma configurations and
coefficient table per the parsed bluetooth link status and given
wifi connection state. The tdma/coef table comes from the vendor
driver code of the RTL8192EU and RTL8723BU. However, this commit is
only for single antenna scenario which RTL8192EU is default dual
antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h
is only for 8723b and 8192e so the mechanism is expected to work
on both chips with single antenna. Note RTL8192EU dual antenna is
not supported.

Signed-off-by: Chris Chiu 
---

Notes:
  v2:
   - Add helper functions to replace bunch of tdma settings
   - Reformat some lines to meet kernel coding style


 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h  |  37 +++
 .../realtek/rtl8xxxu/rtl8xxxu_8723b.c |   2 -
 .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 262 +-
 3 files changed, 294 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 582c2a346cec..22e95b11bfbb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1220,6 +1220,37 @@ enum ratr_table_mode_new {
RATEID_IDX_BGN_3SS = 14,
 };
 
+#define BT_INFO_8723B_1ANT_B_FTP   BIT(7)
+#define BT_INFO_8723B_1ANT_B_A2DP  BIT(6)
+#define BT_INFO_8723B_1ANT_B_HID   BIT(5)
+#define BT_INFO_8723B_1ANT_B_SCO_BUSY  BIT(4)
+#define BT_INFO_8723B_1ANT_B_ACL_BUSY  BIT(3)
+#define BT_INFO_8723B_1ANT_B_INQ_PAGE  BIT(2)
+#define BT_INFO_8723B_1ANT_B_SCO_ESCO  BIT(1)
+#define BT_INFO_8723B_1ANT_B_CONNECTIONBIT(0)
+
+enum _BT_8723B_1ANT_STATUS {
+   BT_8723B_1ANT_STATUS_NON_CONNECTED_IDLE  = 0x0,
+   BT_8723B_1ANT_STATUS_CONNECTED_IDLE  = 0x1,
+   BT_8723B_1ANT_STATUS_INQ_PAGE= 0x2,
+   BT_8723B_1ANT_STATUS_ACL_BUSY= 0x3,
+   BT_8723B_1ANT_STATUS_SCO_BUSY= 0x4,
+   BT_8723B_1ANT_STATUS_ACL_SCO_BUSY= 0x5,
+   BT_8723B_1ANT_STATUS_MAX
+};
+
+struct rtl8xxxu_btcoex {
+   u8  bt_status;
+   boolbt_busy;
+   boolhas_sco;
+   boolhas_a2dp;
+   boolhas_hid;
+   boolhas_pan;
+   boolhid_only;
+   boola2dp_only;
+   boolc2h_bt_inquiry;
+};
+
 #define RTL8XXXU_RATR_STA_INIT 0
 #define RTL8XXXU_RATR_STA_HIGH 1
 #define RTL8XXXU_RATR_STA_MID  2
@@ -1340,6 +1371,10 @@ struct rtl8xxxu_priv {
 */
struct ieee80211_vif *vif;
struct delayed_work ra_watchdog;
+   struct work_struct c2hcmd_work;
+   struct sk_buff_head c2hcmd_queue;
+   spinlock_t c2hcmd_lock;
+   struct rtl8xxxu_btcoex bt_coex;
 };
 
 struct rtl8xxxu_rx_urb {
@@ -1486,6 +1521,8 @@ void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, 
struct ieee80211_hdr *hdr,
 struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
 bool short_preamble, bool ampdu_enable,
 u32 rts_rate);
+void rtl8723bu_set_ps_tdma(struct rtl8xxxu_priv *priv,
+  u8 arg1, u8 arg2, u8 arg3, u8 arg4, u8 arg5);
 
 extern struct rtl8xxxu_fileops rtl8192cu_fops;
 extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index ceffe05bd65b..9ba661b3d767 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1580,9 +1580,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
/*
 * Software control, antenna at WiFi side
 */
-#ifdef NEED_PS_TDMA
rtl8723bu_set_ps_tdma(priv, 0x08, 0x00, 0x00, 0x00, 0x00);
-#endif
 
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE1, 0x);
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE2, 0x);
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a6f358b9e447..e4c1b08c8070 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3820,9 +3820,8 @@ void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv)
rtl8xxxu_write8(priv, REG_RSV_CTRL, 0x0e);
 }
 
-#ifdef

Re: [PATCH] [v2] pinctrl: intel: mark intel_pin_to_gpio __maybe_unused

[Chris Chiu]

On Sat, Sep 7, 2019 at 2:52 AM Arnd Bergmann  wrote:
>
> The intel_pin_to_gpio() function is only called by the
> PM support functions and causes a warning when those are disabled:
>
> drivers/pinctrl/intel/pinctrl-intel.c:841:12: error: unused function 
> 'intel_pin_to_gpio' [-Werror,-Wunused-function]
>
> Mark it __maybe_unused to suppress the warning.
>
> Suggested-by: Andy Shevchenko 
> Signed-off-by: Arnd Bergmann 
Reviewed-by: Chris Chiu