[RFC] ALSA: hda: Add workaround to adapt to Loongson 7A1000 controller

2020-07-30 Thread Kaige Li
There's some issues that cause palyback without a sound on Loongson
platform (3A3000 + 7A1000) with a Realtek ALC269 codec. After lengthy
debugging sessions, we solved it by adding workaround.

Signed-off-by: Kaige Li 
---
 sound/hda/hdac_controller.c| 63 --
 sound/hda/hdac_stream.c| 22 +--
 sound/pci/hda/hda_controller.h |  2 +-
 sound/pci/hda/hda_intel.c  |  9 +-
 4 files changed, 83 insertions(+), 13 deletions(-)

diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c
index 011b17c..f60f49a 100644
--- a/sound/hda/hdac_controller.c
+++ b/sound/hda/hdac_controller.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include "../pci/hda/hda_controller.h"
 #include "local.h"
 
 /* clear CORB read pointer properly */
@@ -42,6 +43,8 @@ static void azx_clear_corbrp(struct hdac_bus *bus)
  */
 void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus)
 {
+   struct azx *chip = bus_to_azx(bus);
+
WARN_ON_ONCE(!bus->rb.area);
 
spin_lock_irq(&bus->reg_lock);
@@ -58,11 +61,15 @@ void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus)
 
/* reset the corb hw read pointer */
snd_hdac_chip_writew(bus, CORBRP, AZX_CORBRP_RST);
-   if (!bus->corbrp_self_clear)
+   if (chip->driver_caps & AZX_DCAPS_LOONGSON_HDA_WORKAROUND)
+   snd_hdac_chip_writew(bus, CORBRP, 0);
+   else if (!bus->corbrp_self_clear)
azx_clear_corbrp(bus);
 
/* enable corb dma */
snd_hdac_chip_writeb(bus, CORBCTL, AZX_CORBCTL_RUN);
+   if (chip->driver_caps & AZX_DCAPS_LOONGSON_HDA_WORKAROUND)
+   snd_hdac_chip_readb(bus, CORBCTL);
 
/* RIRB set up */
bus->rirb.addr = bus->rb.addr + 2048;
@@ -79,7 +86,12 @@ void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus)
/* set N=1, get RIRB response interrupt for new entry */
snd_hdac_chip_writew(bus, RINTCNT, 1);
/* enable rirb dma and response irq */
-   snd_hdac_chip_writeb(bus, RIRBCTL, AZX_RBCTL_DMA_EN | AZX_RBCTL_IRQ_EN);
+   if (chip->driver_caps & AZX_DCAPS_LOONGSON_HDA_WORKAROUND) {
+   snd_hdac_chip_writeb(bus, RIRBCTL, AZX_RBCTL_DMA_EN);
+   snd_hdac_chip_readb(bus, RIRBCTL);
+   } else {
+   snd_hdac_chip_writeb(bus, RIRBCTL, AZX_RBCTL_DMA_EN | 
AZX_RBCTL_IRQ_EN);
+   }
/* Accept unsolicited responses */
snd_hdac_chip_updatel(bus, GCTL, AZX_GCTL_UNSOL, AZX_GCTL_UNSOL);
spin_unlock_irq(&bus->reg_lock);
@@ -132,6 +144,18 @@ static unsigned int azx_command_addr(u32 cmd)
return addr;
 }
 
+static unsigned int azx_response_addr(u32 res)
+{
+   unsigned int addr = res & 0xf;
+
+   if (addr >= AZX_MAX_CODECS) {
+   snd_BUG();
+   addr = 0;
+   }
+
+   return addr;
+}
+
 /**
  * snd_hdac_bus_send_cmd - send a command verb via CORB
  * @bus: HD-audio core bus
@@ -189,6 +213,7 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus)
unsigned int rp, wp;
unsigned int addr;
u32 res, res_ex;
+   struct azx *chip = bus_to_azx(bus);
 
wp = snd_hdac_chip_readw(bus, RIRBWP);
if (wp == 0x) {
@@ -207,7 +232,11 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus)
rp = bus->rirb.rp << 1; /* an RIRB entry is 8-bytes */
res_ex = le32_to_cpu(bus->rirb.buf[rp + 1]);
res = le32_to_cpu(bus->rirb.buf[rp]);
-   addr = res_ex & 0xf;
+   if (chip->driver_caps & AZX_DCAPS_LOONGSON_HDA_WORKAROUND) {
+   addr = azx_response_addr(res_ex);
+   } else {
+   addr = res_ex & 0xf;
+   }
if (addr >= HDA_MAX_CODECS) {
dev_err(bus->dev,
"spurious response %#x:%#x, rp = %d, wp = %d",
@@ -245,6 +274,7 @@ int snd_hdac_bus_get_response(struct hdac_bus *bus, 
unsigned int addr,
unsigned long loopcounter;
wait_queue_entry_t wait;
bool warned = false;
+   struct azx *chip = bus_to_azx(bus);
 
init_wait_entry(&wait, 0);
timeout = jiffies + msecs_to_jiffies(1000);
@@ -254,8 +284,11 @@ int snd_hdac_bus_get_response(struct hdac_bus *bus, 
unsigned int addr,
if (!bus->polling_mode)
prepare_to_wait(&bus->rirb_wq, &wait,
TASK_UNINTERRUPTIBLE);
-   if (bus->polling_mode)
+   if (bus->polling_mode) {
+   if (chip->driver_caps & 
AZX_DCAPS_LOONGSON_HDA_WORKAROUND)
+   bus->rirb.cmds[addr] %= AZX_MAX_RIRB_ENTRIES;
snd_hdac_bus_update_rirb(bus);
+   }
if (!bus->r

Re: [RFC] ALSA: hda: Add workaround to adapt to Loongson 7A1000 controller

2020-07-31 Thread Kaige Li

On 07/31/2020 02:29 PM, Takashi Iwai wrote:


On Fri, 31 Jul 2020 04:41:54 +0200,
Kaige Li wrote:

There's some issues that cause palyback without a sound on Loongson
platform (3A3000 + 7A1000) with a Realtek ALC269 codec. After lengthy
debugging sessions, we solved it by adding workaround.

Signed-off-by: Kaige Li 

Thanks for the patch.  But this can't be taken as is due to the design
problem.  Namely...


--- a/sound/hda/hdac_controller.c
+++ b/sound/hda/hdac_controller.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include "../pci/hda/hda_controller.h"

... here already suspicious, and ...


  #include "local.h"
  
  /* clear CORB read pointer properly */

@@ -42,6 +43,8 @@ static void azx_clear_corbrp(struct hdac_bus *bus)
   */
  void snd_hdac_bus_init_cmd_io(struct hdac_bus *bus)
  {
+   struct azx *chip = bus_to_azx(bus);

... here you cast the hdac_bus object to its child class.  This is
disallowed, as it's a layer violation and would break if another child
class like ASoC driver is used with this patch.

IOW, inside the code in sound/hda/*, you must not use the contents in
sound/pci/hda/* and include/sound/hda_codec.h.

If any new workaround is needed, introduce a new flag in struct
hdac_bus.


Thank you for your reply and suggestions. I will review it, and see how 
hdac_bus works.


Thanks,
Kaige

thanks,

Takashi




[RESEND] NTB: hw: amd: fix an issue about leak system resources

2020-08-10 Thread Kaige Li
The related system resources were not released when pci_set_dma_mask(),
pci_set_consistent_dma_mask(), or pci_iomap() return error in the
amd_ntb_init_pci() function. Add pci_release_regions() to fix it.

Signed-off-by: Kaige Li 
---

changed commit massage.

 drivers/ntb/hw/amd/ntb_hw_amd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index 88e1db6..71428d8 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.c
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -1203,6 +1203,7 @@ static int amd_ntb_init_pci(struct amd_ntb_dev *ndev,
 
 err_dma_mask:
pci_clear_master(pdev);
+   pci_release_regions(pdev);
 err_pci_regions:
pci_disable_device(pdev);
 err_pci_enable:
-- 
2.1.0



[PATCH] net: phy: mscc: Fix a couple of spelling mistakes "spcified" -> "specified"

2020-08-19 Thread Kaige Li
There are a couple of spelling mistakes in comment text. Fix these.

Signed-off-by: Kaige Li 
---
 drivers/net/phy/mscc/mscc_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/mscc/mscc_main.c b/drivers/net/phy/mscc/mscc_main.c
index a4fbf3a..6bc7406 100644
--- a/drivers/net/phy/mscc/mscc_main.c
+++ b/drivers/net/phy/mscc/mscc_main.c
@@ -1738,13 +1738,13 @@ static int __phy_write_mcb_s6g(struct phy_device 
*phydev, u32 reg, u8 mcb,
return 0;
 }
 
-/* Trigger a read to the spcified MCB */
+/* Trigger a read to the specified MCB */
 static int phy_update_mcb_s6g(struct phy_device *phydev, u32 reg, u8 mcb)
 {
return __phy_write_mcb_s6g(phydev, reg, mcb, PHY_MCB_S6G_READ);
 }
 
-/* Trigger a write to the spcified MCB */
+/* Trigger a write to the specified MCB */
 static int phy_commit_mcb_s6g(struct phy_device *phydev, u32 reg, u8 mcb)
 {
return __phy_write_mcb_s6g(phydev, reg, mcb, PHY_MCB_S6G_WRITE);
-- 
2.1.0



[PATCH] scsi: lpfc: fix typo

2020-08-20 Thread Kaige Li
Fix spelling mistake: "Cant" -> "Can't"

Signed-off-by: Kaige Li 
---
 drivers/scsi/lpfc/lpfc_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index ae0a825..d6c07ee 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -5944,7 +5944,7 @@ lpfc_debugfs_initialize(struct lpfc_vport *vport)
phba, &lpfc_debugfs_op_lockstat);
if (!phba->debug_lockstat) {
lpfc_printf_vlog(vport, KERN_ERR, LOG_INIT,
-"4610 Cant create debugfs lockstat\n");
+"4610 Can't create debugfs 
lockstat\n");
goto debug_failed;
}
 #endif
-- 
2.1.0



Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-07-02 Thread Kaige Li



On 06/25/2020 12:59 AM, Jakub Kicinski wrote:

On Wed, 24 Jun 2020 06:32:36 + Christian Benvenuti (benve) wrote:

We/Cisco will also look into it, hopefully a small code reorg will be 
sufficient.


Hi, Christian:

I have seen some submissions and codes, and feel that spin_lock is unnecessary in 
enci_reset.



Some key submissions are as follows.

Tue Sep 16 00:17:11 2008

git show 01f2e4ead. we can see that spin_lock is just in here:

+   spin_lock(&enic->devcmd_lock);

+   vnic_dev_hang_notify(enic->vdev);

+   spin_unlock(&enic->devcmd_lock);



Sat Aug 17 06:47:40 2013

git show 0b038566c: Add an interface for USNIC to interact with firmware.

Before commit-id: 0b038566c, spin_lock is not used in enic_reset. rtnl_lock() 
is enough. And 0b038566c add a interface: enic_api_devcmd_proxy_by_index.

Enic_api_devcmd_proxy_by_index is just used in 
./drivers/infiniband/hw/usnic/usnic_fwd.c:50, which is added in 2183b990.

+   spin_lock(&enic->enic_api_lock);

enic_dev_hang_notify(enic);


enic_dev_set_ig_vlan_rewrite_mode(enic);

enic_open(enic->netdev);

+   spin_unlock(&enic->enic_api_lock);

By analyzing enic_api_lock, it's mainly used for locking vnic_dev_cmd(vdev, 
cmd, a0, a1, wait). And enic_reset didn't call to vnic_dev_cmd.

So, I think spin_lock may be deleted in enci_reset. What do you think? Or you 
have better advice.

Thank you.


Make sure you enable CONFIG_DEBUG_ATOMIC_SLEEP when you test.




[PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-22 Thread Kaige Li
The kernel module may sleep with holding a spinlock.

The function call paths (from bottom to top) are:

[FUNC] zalloc_cpumask_var(GFP_KERNEL)
drivers/net/ethernet/cisco/enic/enic_main.c, 125: zalloc_cpumask_var in 
enic_init_affinity_hint
drivers/net/ethernet/cisco/enic/enic_main.c, 1918: enic_init_affinity_hint in 
enic_open
drivers/net/ethernet/cisco/enic/enic_main.c, 2348: enic_open in enic_reset
drivers/net/ethernet/cisco/enic/enic_main.c, 2341: spin_lock in enic_reset

To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.

Signed-off-by: Kaige Li 
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c 
b/drivers/net/ethernet/cisco/enic/enic_main.c
index cd5fe4f..ee62065 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -122,7 +122,7 @@ static void enic_init_affinity_hint(struct enic *enic)
 !cpumask_empty(enic->msix[i].affinity_mask)))
continue;
if (zalloc_cpumask_var(&enic->msix[i].affinity_mask,
-  GFP_KERNEL))
+  GFP_ATOMIC))
cpumask_set_cpu(cpumask_local_spread(i, numa_node),
enic->msix[i].affinity_mask);
}
-- 
2.1.0



Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-23 Thread Kaige Li

On 06/23/2020 12:09 PM, David Miller wrote:

Networking changes must be submitted with net...@vger.kernel.org


Thanks for your reply, sorry for that. I will resend this patch.



Thank you.




[PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-23 Thread Kaige Li
The kernel module may sleep with holding a spinlock.

The function call paths (from bottom to top) are:

[FUNC] zalloc_cpumask_var(GFP_KERNEL)
drivers/net/ethernet/cisco/enic/enic_main.c, 125: zalloc_cpumask_var in 
enic_init_affinity_hint
drivers/net/ethernet/cisco/enic/enic_main.c, 1918: enic_init_affinity_hint in 
enic_open
drivers/net/ethernet/cisco/enic/enic_main.c, 2348: enic_open in enic_reset
drivers/net/ethernet/cisco/enic/enic_main.c, 2341: spin_lock in enic_reset

To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.

Signed-off-by: Kaige Li 
---

+cc net...@vger.kernel.org

 drivers/net/ethernet/cisco/enic/enic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c 
b/drivers/net/ethernet/cisco/enic/enic_main.c
index cd5fe4f..ee62065 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -122,7 +122,7 @@ static void enic_init_affinity_hint(struct enic *enic)
 !cpumask_empty(enic->msix[i].affinity_mask)))
continue;
if (zalloc_cpumask_var(&enic->msix[i].affinity_mask,
-  GFP_KERNEL))
+  GFP_ATOMIC))
cpumask_set_cpu(cpumask_local_spread(i, numa_node),
enic->msix[i].affinity_mask);
}
-- 
2.1.0



Re: [PATCH 1/2] ALSA: hda/realtek: Fix headset mic on Loongson platform

2020-07-19 Thread Kaige Li



On 07/17/2020 02:57 PM, Takashi Iwai wrote:

On Fri, 17 Jul 2020 04:51:31 +0200,
Kaige Li wrote:

Add pin quirks to enable use of the headset mic on Loongson platform.

Signed-off-by: Kaige Li 
@@ -7654,6 +7663,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", 
ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
+   SND_PCI_QUIRK(0x10ec, 0x0269, "Loongson HDA", 
ALC269_FIXUP_LOONGSON_HDA),

This is basically Realtek ALC269 codec itself, so putting this here
may hit with many other machines.

Doesn't it has any proper PCI or codec SSID?  The lack of them usually
means a bug of BIOS.


 Ok, I will have a look. If there is any progress, I will reply to you again.

 Thank you!

 Kaige


thanks,

Takashi




Re: [PATCH 1/2] ALSA: hda/realtek: Fix headset mic on Loongson platform

2020-07-23 Thread Kaige Li

On 07/20/2020 09:58 AM, Kaige Li wrote:



On 07/17/2020 02:57 PM, Takashi Iwai wrote:

On Fri, 17 Jul 2020 04:51:31 +0200,
Kaige Li wrote:

Add pin quirks to enable use of the headset mic on Loongson platform.

Signed-off-by: Kaige Li 
@@ -7654,6 +7663,7 @@ static const struct snd_pci_quirk 
alc269_fixup_tbl[] = {
  SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", 
ALC269_FIXUP_PCM_44K),
  SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", 
ALC269_FIXUP_LENOVO_EAPD),
  SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", 
ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
+SND_PCI_QUIRK(0x10ec, 0x0269, "Loongson HDA", 
ALC269_FIXUP_LOONGSON_HDA),

This is basically Realtek ALC269 codec itself, so putting this here
may hit with many other machines.

Doesn't it has any proper PCI or codec SSID?  The lack of them usually
means a bug of BIOS.


 Ok, I will have a look. If there is any progress, I will reply to you 
again.
Sorry for that, there is no proper PCI or codec SSID. We have fixed this 
by writing the firmware. So this patch is useless.


Thank you for your time!

Kaige


 Thank you!

 Kaige


thanks,

Takashi






[PATCH] NTB: hw: amd: Add missed pci_release_region

2020-07-24 Thread Kaige Li
The driver forgets to call pci_release_region() in init_pci failure.
Add the missed call to fix it.

Signed-off-by: Kaige Li 
---
 drivers/ntb/hw/amd/ntb_hw_amd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index 88e1db6..71428d8 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.c
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -1203,6 +1203,7 @@ static int amd_ntb_init_pci(struct amd_ntb_dev *ndev,
 
 err_dma_mask:
pci_clear_master(pdev);
+   pci_release_regions(pdev);
 err_pci_regions:
pci_disable_device(pdev);
 err_pci_enable:
-- 
2.1.0



[PATCH 2/2] ALSA: hda: Add support for Loongson 7A1000 controller

2020-07-16 Thread Kaige Li
Add the new PCI ID 0x0014 0x7a07 to support Loongson 7A1000 controller.

Signed-off-by: Kaige Li 
---
 sound/pci/hda/hda_intel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1625721..ea1d535 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2735,6 +2735,8 @@ static const struct pci_device_id azx_ids[] = {
  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI },
/* Zhaoxin */
{ PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN },
+   /* Loongson */
+   { PCI_DEVICE(0x0014, 0x7a07), .driver_data = AZX_DRIVER_GENERIC },
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);
-- 
2.1.0



[PATCH 1/2] ALSA: hda/realtek: Fix headset mic on Loongson platform

2020-07-16 Thread Kaige Li
Add pin quirks to enable use of the headset mic on Loongson platform.

Signed-off-by: Kaige Li 
---
 sound/pci/hda/patch_realtek.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 4c7e191..b227be3 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6041,6 +6041,7 @@ enum {
ALC290_FIXUP_SUBWOOFER_HSJACK,
ALC269_FIXUP_THINKPAD_ACPI,
ALC269_FIXUP_DMIC_THINKPAD_ACPI,
+   ALC269_FIXUP_LOONGSON_HDA,
ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
ALC255_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC255_FIXUP_DELL1_MIC_NO_PRESENCE,
@@ -6381,6 +6382,14 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+   [ALC269_FIXUP_LOONGSON_HDA] = {
+   .type = HDA_FIXUP_PINS,
+   .v.pins = (const struct hda_pintbl[]) {
+   { 0x1b, 0x02214c40 }, /* Front Mic */
+   { 0x15, 0x01014030 }, /* Rear Mic */
+   { }
+   },
+   },
[ALC269_FIXUP_DELL4_MIC_NO_PRESENCE] = {
.type = HDA_FIXUP_PINS,
.v.pins = (const struct hda_pintbl[]) {
@@ -7654,6 +7663,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
SND_PCI_QUIRK(0x19e5, 0x3204, "Huawei MACH-WX9", 
ALC256_FIXUP_HUAWEI_MACH_WX9_PINS),
+   SND_PCI_QUIRK(0x10ec, 0x0269, "Loongson HDA", 
ALC269_FIXUP_LOONGSON_HDA),
SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", 
ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
SND_PCI_QUIRK(0x1d72, 0x1901, "RedmiBook 14", 
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x10ec, 0x118c, "Medion EE4254 MD62100", 
ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE),
-- 
2.1.0



[PATCH] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-22 Thread Kaige Li
The kernel module may sleep with holding a spinlock.

The function call paths (from bottom to top) are:

[FUNC] zalloc_cpumask_var(GFP_KERNEL)
drivers/net/ethernet/cisco/enic/enic_main.c, 125: zalloc_cpumask_var in 
enic_init_affinity_hint
drivers/net/ethernet/cisco/enic/enic_main.c, 1918: enic_init_affinity_hint in 
enic_open
drivers/net/ethernet/cisco/enic/enic_main.c, 2348: enic_open in enic_reset
drivers/net/ethernet/cisco/enic/enic_main.c, 2341: spin_lock in enic_reset

To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.

Signed-off-by: Kaige Li 
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c 
b/drivers/net/ethernet/cisco/enic/enic_main.c
index cd5fe4f..ee62065 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -122,7 +122,7 @@ static void enic_init_affinity_hint(struct enic *enic)
 !cpumask_empty(enic->msix[i].affinity_mask)))
continue;
if (zalloc_cpumask_var(&enic->msix[i].affinity_mask,
-  GFP_KERNEL))
+  GFP_ATOMIC))
cpumask_set_cpu(cpumask_local_spread(i, numa_node),
enic->msix[i].affinity_mask);
}
-- 
2.1.0



[PATCH] perf/core: Do not initialise statics to 0 and add space before '{'

2020-05-07 Thread Kaige Li
Fix the following checkpatch errors:

ERROR: do not initialise statics to 0
#10616: FILE: ./kernel/events/core.c:10616:
+ static int hw_context_taken = 0;

ERROR: space required before the open brace '{'
#11070: FILE: ./kernel/events/core.c:11070:
+ } else if (is_write_backward(event)){

Signed-off-by: Kaige Li 
---
 kernel/events/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 80cf996..8d47d30 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10618,7 +10618,7 @@ int perf_pmu_register(struct pmu *pmu, const char 
*name, int type)
 
 skip_type:
if (pmu->task_ctx_nr == perf_hw_context) {
-   static int hw_context_taken = 0;
+   static int hw_context_taken;
 
/*
 * Other than systems with heterogeneous CPUs, it never makes
@@ -11072,7 +11072,7 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
if (overflow_handler) {
event->overflow_handler = overflow_handler;
event->overflow_handler_context = context;
-   } else if (is_write_backward(event)){
+   } else if (is_write_backward(event)) {
event->overflow_handler = perf_event_output_backward;
event->overflow_handler_context = NULL;
} else {
-- 
2.1.0



Re: [PATCH] perf/core: Do not initialise statics to 0 and add space before '{'

2020-05-08 Thread Kaige Li



Ok, I will pay attation. thank you.


On 05/08/2020 04:25 PM, Peter Zijlstra wrote:

Checkpatch can sod off. Please don't ever submit pure checkpatch patches
to anything I maintain




Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-23 Thread Kaige Li



On 06/24/2020 06:26 AM, David Miller wrote:

From: David Miller 
Date: Tue, 23 Jun 2020 14:33:11 -0700 (PDT)


Calling a NIC driver open function from a context holding a spinlock
is very much the real problem, so many operations have to sleep and
in face that ->ndo_open() method is defined as being allowed to sleep
and that's why the core networking never invokes it with spinlocks

   

I mean "without" of course. :-)


held.


Did you mean that open function should be out of spinlock? If so, I will
send V2 patch.

Thank you.



Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-23 Thread Kaige Li



On 06/24/2020 04:50 AM, Jakub Kicinski wrote:

On Tue, 23 Jun 2020 16:13:09 +0800 Kaige Li wrote:

The kernel module may sleep with holding a spinlock.

The function call paths (from bottom to top) are:

[FUNC] zalloc_cpumask_var(GFP_KERNEL)
drivers/net/ethernet/cisco/enic/enic_main.c, 125: zalloc_cpumask_var in 
enic_init_affinity_hint
drivers/net/ethernet/cisco/enic/enic_main.c, 1918: enic_init_affinity_hint in 
enic_open
drivers/net/ethernet/cisco/enic/enic_main.c, 2348: enic_open in enic_reset
drivers/net/ethernet/cisco/enic/enic_main.c, 2341: spin_lock in enic_reset

To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC.

Signed-off-by: Kaige Li 

I don't think this is sufficient. Calling open with a spin lock held
seems like a very bad idea. At a quick look the driver also calls
request_irq() from open - request_irq() can sleep.


You are right. Should I do spin_unlock before the enic_open, or remove
spin_lock in enic_reset?

Thank you.



Re: [PATCH RESEND] net/cisco: Fix a sleep-in-atomic-context bug in enic_init_affinity_hint()

2020-06-23 Thread Kaige Li



On 06/24/2020 11:23 AM, David Miller wrote:

From: Kaige Li 
Date: Wed, 24 Jun 2020 09:56:47 +0800


On 06/24/2020 06:26 AM, David Miller wrote:

From: David Miller 
Date: Tue, 23 Jun 2020 14:33:11 -0700 (PDT)


Calling a NIC driver open function from a context holding a spinlock
is very much the real problem, so many operations have to sleep and
in face that ->ndo_open() method is defined as being allowed to sleep
and that's why the core networking never invokes it with spinlocks



I mean "without" of course. :-)


held.

Did you mean that open function should be out of spinlock? If so, I
will
send V2 patch.

Yes, but only if that is safe.

You have to analyze the locking done by this driver and fix it properly.
I anticipate it is not just a matter of changing where the spinlock
is held, you will have to rearchitect things a bit.


Okay, I will careful analyze this question, and make a suitable patch in V2.

Thank you.