[PATCH] gpu: drm: mediatek: delete redundant printing of return value
platform_get_irq() has already checked and printed the return value,
the printing here is nothing special, it is not necessary at all.
Signed-off-by: Wang Qing
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index b05f900..0ac4962
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -751,10 +751,8 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
dpi->irq = platform_get_irq(pdev, 0);
- if (dpi->irq <= 0) {
- dev_err(dev, "Failed to get irq: %d\n", dpi->irq);
+ if (dpi->irq <= 0)
return -EINVAL;
- }
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
NULL, &dpi->next_bridge);
--
2.7.4
[PATCH] tty: serial: 8250: delete redundant printing of return value
platform_get_irq() has already checked and printed the return value,
the printing here is nothing special, it is not necessary at all.
Signed-off-by: Wang Qing
---
drivers/tty/serial/8250/8250_fsl.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_fsl.c
b/drivers/tty/serial/8250/8250_fsl.c
index fbcc90c..cd19400
--- a/drivers/tty/serial/8250/8250_fsl.c
+++ b/drivers/tty/serial/8250/8250_fsl.c
@@ -104,11 +104,8 @@ static int fsl8250_acpi_probe(struct platform_device *pdev)
}
irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
- if (irq != -EPROBE_DEFER)
- dev_err(dev, "cannot get irq\n");
+ if (irq < 0)
return irq;
- }
memset(&port8250, 0, sizeof(port8250));
--
2.7.4
[PATCH] char: hw_random: delete redundant printing of return value
platform_get_irq() has already checked and printed the return value,
the printing here is nothing special, it is not necessary at all.
Signed-off-by: Wang Qing
---
drivers/char/hw_random/cctrng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/cctrng.c b/drivers/char/hw_random/cctrng.c
index 7a293f2..1e551e3
--- a/drivers/char/hw_random/cctrng.c
+++ b/drivers/char/hw_random/cctrng.c
@@ -527,10 +527,8 @@ static int cctrng_probe(struct platform_device *pdev)
/* Then IRQ */
irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
- dev_err(dev, "Failed getting IRQ resource\n");
+ if (irq < 0)
return irq;
- }
/* parse sampling rate from device tree */
rc = cc_trng_parse_sampling_ratio(drvdata);
--
2.7.4
[PATCH 1/2] ata: delete redundant printing of return value
platform_get_irq() has already checked and printed the return value,
the printing here is nothing special, it is not necessary at all.
Signed-off-by: Wang Qing
---
drivers/ata/sata_highbank.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/ata/sata_highbank.c b/drivers/ata/sata_highbank.c
index 64b2ef1..a43d42a
--- a/drivers/ata/sata_highbank.c
+++ b/drivers/ata/sata_highbank.c
@@ -469,10 +469,8 @@ static int ahci_highbank_probe(struct platform_device
*pdev)
}
irq = platform_get_irq(pdev, 0);
- if (irq <= 0) {
- dev_err(dev, "no irq\n");
+ if (irq <= 0)
return -EINVAL;
- }
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
if (!hpriv) {
--
2.7.4
[PATCH 1/2] ata: delete redundant printing of return value
platform_get_irq() has already checked and printed the return value,
the printing here is nothing special, it is not necessary at all.
Signed-off-by: Wang Qing
---
drivers/ata/libahci_platform.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index de638da..2e7ea75
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -582,11 +582,8 @@ int ahci_platform_init_host(struct platform_device *pdev,
int i, irq, n_ports, rc;
irq = platform_get_irq(pdev, 0);
- if (irq <= 0) {
- if (irq != -EPROBE_DEFER)
- dev_err(dev, "no irq\n");
+ if (irq <= 0)
return irq;
- }
hpriv->irq = irq;
--
2.7.4
Re: [v8,3/7] PCI: mediatek-gen3: Add MediaTek Gen3 driver for MT8192
On Thu, 2021-03-11 at 13:38 +0100, Pali Rohár wrote:
> On Wednesday 24 February 2021 14:11:28 Jianjun Wang wrote:
> > +static int mtk_pcie_startup_port(struct mtk_pcie_port *port)
> > +{
> ...
> > +
> > + /* Delay 100ms to wait the reference clocks become stable */
> > + msleep(100);
> > +
> > + /* De-assert PERST# signal */
> > + val &= ~PCIE_PE_RSTB;
> > + writel_relaxed(val, port->base + PCIE_RST_CTRL_REG);
>
> Hello! This is a new driver which introduce yet another custom timeout
> prior PERST# signal for PCIe card is de-asserted. Timeouts for other
> drivers I collected in older email [2].
>
> Please look at my email [1] about PCIe Warm Reset if you have any clue
> about it. Lorenzo and Rob already expressed that this timeout should not
> be driver specific. But nobody was able to "decode" and "understand"
> PCIe spec yet about these timeouts.
Hi Pali,
I think this is more like a platform specific timeout, which is used to
wait for the reference clocks to become stable and finish the reset flow
of HW blocks.
Here is the steps to start a link training in this HW:
1. Assert all reset signals which including the transaction layer, PIPE
interface and internal bus interface;
2. De-assert reset signals except the PERST#, this will make the
physical layer active and start to output the reference clock, but the
EP device remains in the reset state.
Before releasing the PERST# signal, the HW blocks needs at least 10ms
to finish the reset flow, and ref-clk needs about 30us to become stable.
3. De-assert PERST# signal, wait LTSSM enter L0 state.
This 100ms timeout is reference to TPVPERL in the PCIe CEM spec. Since
we are in the kernel stage, the power supply has already stabled, this
timeout may not take that long.
> > +
> > + /* Check if the link is up or not */
> > + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_REG, val,
> > +!!(val & PCIE_PORT_LINKUP), 20,
> > +50 * USEC_PER_MSEC);
>
> IIRC, you need to wait at least 100ms after de-asserting PERST# signal
> as it is required by PCIe specs and also because experiments proved that
> some Compex wifi cards (e.g. WLE900VX) are not detected if you do not
> wait this minimal time.
Yes, this should be 100ms, I will fix it at next version, thanks for
your review.
Thanks.
>
> > + if (err) {
> > + val = readl_relaxed(port->base + PCIE_LTSSM_STATUS_REG);
> > + dev_err(port->dev, "PCIe link down, ltssm reg val: %#x\n", val);
> > + return err;
> > + }
>
> [1] - https://lore.kernel.org/linux-pci/20210310110535.zh4pnn4vpmvzwl5q@pali/
> [2] - https://lore.kernel.org/linux-pci/20200424092546.25p3hdtkehohe3xw@pali/
[PATCH v4 1/3] crypto: hisilicon/sec - fixes a printing error
When the log is output here, the device has not
been initialized yet.
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index f835514..2176e4d 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -546,7 +546,7 @@ static int sec_skcipher_init(struct crypto_skcipher *tfm)
crypto_skcipher_set_reqsize(tfm, sizeof(struct sec_req));
ctx->c_ctx.ivsize = crypto_skcipher_ivsize(tfm);
if (ctx->c_ctx.ivsize > SEC_IV_SIZE) {
- dev_err(SEC_CTX_DEV(ctx), "get error skcipher iv size!\n");
+ pr_err("get error skcipher iv size!\n");
return -EINVAL;
}
--
2.8.1
[PATCH v4 3/3] crypto: hisilicon/sec - fixes some driver coding style
cleanup static check errors for SEC
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec_main.c | 131 ++-
1 file changed, 76 insertions(+), 55 deletions(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec_main.c
b/drivers/crypto/hisilicon/sec2/sec_main.c
index dc68ba7..78a6043 100644
--- a/drivers/crypto/hisilicon/sec2/sec_main.c
+++ b/drivers/crypto/hisilicon/sec2/sec_main.c
@@ -35,15 +35,13 @@
#define SEC_CTX_Q_NUM_MAX 32
#define SEC_CTRL_CNT_CLR_CE0x301120
-#define SEC_CTRL_CNT_CLR_CE_BITBIT(0)
-#define SEC_ENGINE_PF_CFG_OFF 0x30
-#define SEC_ACC_COMMON_REG_OFF 0x1000
+#define SEC_CTRL_CNT_CLR_CE_BITBIT(0)
#define SEC_CORE_INT_SOURCE0x301010
#define SEC_CORE_INT_MASK 0x301000
#define SEC_CORE_INT_STATUS0x301008
#define SEC_CORE_SRAM_ECC_ERR_INFO 0x301C14
-#define SEC_ECC_NUM(err) (((err) >> 16) & 0xFF)
-#define SEC_ECC_ADDR(err) ((err) >> 0)
+#define SEC_ECC_NUM16
+#define SEC_ECC_MASH 0xFF
#define SEC_CORE_INT_DISABLE 0x0
#define SEC_CORE_INT_ENABLE0x1ff
#define SEC_CORE_INT_CLEAR 0x1ff
@@ -55,23 +53,23 @@
#define SEC_RAS_CE_ENB_MSK 0x88
#define SEC_RAS_FE_ENB_MSK 0x0
#define SEC_RAS_NFE_ENB_MSK0x177
-#define SEC_RAS_DISABLE0x0
-#define SEC_MEM_START_INIT_REG 0x0100
-#define SEC_MEM_INIT_DONE_REG 0x0104
+#define SEC_RAS_DISABLE0x0
+#define SEC_MEM_START_INIT_REG 0x301100
+#define SEC_MEM_INIT_DONE_REG 0x301104
-#define SEC_CONTROL_REG0x0200
+#define SEC_CONTROL_REG0x301200
#define SEC_TRNG_EN_SHIFT 8
#define SEC_CLK_GATE_ENABLEBIT(3)
#define SEC_CLK_GATE_DISABLE (~BIT(3))
#define SEC_AXI_SHUTDOWN_ENABLEBIT(12)
#define SEC_AXI_SHUTDOWN_DISABLE 0xEFFF
-#define SEC_INTERFACE_USER_CTRL0_REG 0x0220
-#define SEC_INTERFACE_USER_CTRL1_REG 0x0224
-#define SEC_SAA_EN_REG 0x0270
-#define SEC_BD_ERR_CHK_EN_REG0 0x0380
-#define SEC_BD_ERR_CHK_EN_REG1 0x0384
-#define SEC_BD_ERR_CHK_EN_REG3 0x038c
+#define SEC_INTERFACE_USER_CTRL0_REG 0x301220
+#define SEC_INTERFACE_USER_CTRL1_REG 0x301224
+#define SEC_SAA_EN_REG 0x301270
+#define SEC_BD_ERR_CHK_EN_REG0 0x301380
+#define SEC_BD_ERR_CHK_EN_REG1 0x301384
+#define SEC_BD_ERR_CHK_EN_REG3 0x30138c
#define SEC_USER0_SMMU_NORMAL (BIT(23) | BIT(15))
#define SEC_USER1_SMMU_NORMAL (BIT(31) | BIT(23) | BIT(15) | BIT(7))
@@ -95,9 +93,6 @@
#define SEC_SQE_MASK_OFFSET64
#define SEC_SQE_MASK_LEN 48
-#define SEC_ADDR(qm, offset) ((qm)->io_base + (offset) + \
-SEC_ENGINE_PF_CFG_OFF + SEC_ACC_COMMON_REG_OFF)
-
struct sec_hw_error {
u32 int_msk;
const char *msg;
@@ -117,16 +112,43 @@ static struct hisi_qm_list sec_devices = {
};
static const struct sec_hw_error sec_hw_errors[] = {
- {.int_msk = BIT(0), .msg = "sec_axi_rresp_err_rint"},
- {.int_msk = BIT(1), .msg = "sec_axi_bresp_err_rint"},
- {.int_msk = BIT(2), .msg = "sec_ecc_2bit_err_rint"},
- {.int_msk = BIT(3), .msg = "sec_ecc_1bit_err_rint"},
- {.int_msk = BIT(4), .msg = "sec_req_trng_timeout_rint"},
- {.int_msk = BIT(5), .msg = "sec_fsm_hbeat_rint"},
- {.int_msk = BIT(6), .msg = "sec_channel_req_rng_timeout_rint"},
- {.int_msk = BIT(7), .msg = "sec_bd_err_rint"},
- {.int_msk = BIT(8), .msg = "sec_chain_buff_err_rint"},
- { /* sentinel */ }
+ {
+ .int_msk = BIT(0),
+ .msg = "sec_axi_rresp_err_rint"
+ },
+ {
+ .int_msk = BIT(1),
+ .msg = "sec_axi_bresp_err_rint"
+ },
+ {
+ .int_msk = BIT(2),
+ .msg = "sec_ecc_2bit_err_rint"
+ },
+ {
+ .int_msk = BIT(3),
+ .msg = "sec_ecc_1bit_err_rint"
+ },
+ {
+ .int_msk = BIT(4),
+ .msg = "sec_req_trng_timeout_rint"
+ },
+ {
+ .int_msk = BIT(5),
+ .msg = "sec_fsm_hbeat_rint"
+ },
+ {
+ .int_msk = BIT(6),
+ .msg = "sec_channel_req_rng_timeout_rint"
+ },
+ {
+ .int_msk = BIT(7),
+ .msg = "sec_bd_err_rint"
+ },
+ {
+ .int_msk = BIT(8),
+ .msg = "sec_chain_buff_err_rint"
+ },
+ {}
};
static const char * const sec_dbg_file_name[] = {
@@ -277,9 +299,7 @@ static u8 sec_get_endian(struct hisi_qm *qm)
"cannot access a register in VF!\n");
return SEC_L
[PATCH v4 2/3] crypto: hisilicon/sec - fixes some coding style
1.delete the original complex method of obtaining the
current device and replace it with the initialized
device pointer.
2.fixes some coding style
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec.h| 5 +-
drivers/crypto/hisilicon/sec2/sec_crypto.c | 75 +++---
drivers/crypto/hisilicon/sec2/sec_crypto.h | 2 -
3 files changed, 39 insertions(+), 43 deletions(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec.h
b/drivers/crypto/hisilicon/sec2/sec.h
index 17ddb20..f7eba9b 100644
--- a/drivers/crypto/hisilicon/sec2/sec.h
+++ b/drivers/crypto/hisilicon/sec2/sec.h
@@ -4,8 +4,6 @@
#ifndef __HISI_SEC_V2_H
#define __HISI_SEC_V2_H
-#include
-
#include "../qm.h"
#include "sec_crypto.h"
@@ -50,7 +48,7 @@ struct sec_req {
int err_type;
int req_id;
- int flag;
+ u32 flag;
/* Status of the SEC request */
bool fake_busy;
@@ -139,6 +137,7 @@ struct sec_ctx {
bool pbuf_supported;
struct sec_cipher_ctx c_ctx;
struct sec_auth_ctx a_ctx;
+ struct device *dev;
};
enum sec_endian {
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2176e4d..c0efa61 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -43,7 +43,6 @@
#define SEC_TOTAL_IV_SZ(SEC_IV_SIZE * QM_Q_DEPTH)
#define SEC_SGL_SGE_NR 128
-#define SEC_CTX_DEV(ctx) (&(ctx)->sec->qm.pdev->dev)
#define SEC_CIPHER_AUTH0xfe
#define SEC_AUTH_CIPHER0x1
#define SEC_MAX_MAC_LEN64
@@ -96,7 +95,7 @@ static int sec_alloc_req_id(struct sec_req *req, struct
sec_qp_ctx *qp_ctx)
0, QM_Q_DEPTH, GFP_ATOMIC);
mutex_unlock(&qp_ctx->req_lock);
if (unlikely(req_id < 0)) {
- dev_err(SEC_CTX_DEV(req->ctx), "alloc req id fail!\n");
+ dev_err(req->ctx->dev, "alloc req id fail!\n");
return req_id;
}
@@ -112,7 +111,7 @@ static void sec_free_req_id(struct sec_req *req)
int req_id = req->req_id;
if (unlikely(req_id < 0 || req_id >= QM_Q_DEPTH)) {
- dev_err(SEC_CTX_DEV(req->ctx), "free request id invalid!\n");
+ dev_err(req->ctx->dev, "free request id invalid!\n");
return;
}
@@ -138,7 +137,7 @@ static int sec_aead_verify(struct sec_req *req)
aead_req->cryptlen + aead_req->assoclen -
authsize);
if (unlikely(sz != authsize || memcmp(mac_out, mac, sz))) {
- dev_err(SEC_CTX_DEV(req->ctx), "aead verify failure!\n");
+ dev_err(req->ctx->dev, "aead verify failure!\n");
return -EBADMSG;
}
@@ -177,7 +176,7 @@ static void sec_req_cb(struct hisi_qp *qp, void *resp)
if (unlikely(req->err_type || done != SEC_SQE_DONE ||
(ctx->alg_type == SEC_SKCIPHER && flag != SEC_SQE_CFLAG) ||
(ctx->alg_type == SEC_AEAD && flag != SEC_SQE_AEAD_FLAG))) {
- dev_err(SEC_CTX_DEV(ctx),
+ dev_err_ratelimited(ctx->dev,
"err_type[%d],done[%d],flag[%d]\n",
req->err_type, done, flag);
err = -EIO;
@@ -326,8 +325,8 @@ static int sec_alloc_pbuf_resource(struct device *dev,
struct sec_alg_res *res)
static int sec_alg_resource_alloc(struct sec_ctx *ctx,
struct sec_qp_ctx *qp_ctx)
{
- struct device *dev = SEC_CTX_DEV(ctx);
struct sec_alg_res *res = qp_ctx->res;
+ struct device *dev = ctx->dev;
int ret;
ret = sec_alloc_civ_resource(dev, res);
@@ -360,7 +359,7 @@ static int sec_alg_resource_alloc(struct sec_ctx *ctx,
static void sec_alg_resource_free(struct sec_ctx *ctx,
struct sec_qp_ctx *qp_ctx)
{
- struct device *dev = SEC_CTX_DEV(ctx);
+ struct device *dev = ctx->dev;
sec_free_civ_resource(dev, qp_ctx->res);
@@ -373,7 +372,7 @@ static void sec_alg_resource_free(struct sec_ctx *ctx,
static int sec_create_qp_ctx(struct hisi_qm *qm, struct sec_ctx *ctx,
int qp_ctx_id, int alg_type)
{
- struct device *dev = SEC_CTX_DEV(ctx);
+ struct device *dev = ctx->dev;
struct sec_qp_ctx *qp_ctx;
struct hisi_qp *qp;
int ret = -ENOMEM;
@@ -428,7 +427,7 @@ static int sec_create_qp_ctx(struct hisi_qm *qm, struct
sec_ctx *ctx,
static void sec_release_qp_ctx(struct sec_ctx *ctx,
struct sec_qp_ctx *qp_ctx)
{
- struct device *dev = SEC_CTX_DEV(ctx);
+ struct device *dev = ctx->dev;
hisi_qm_stop_qp(qp_ctx->qp);
sec_alg_resource_free(ctx, qp_ctx);
@@ -452,6 +451,7 @@ static int sec_ctx_base_init(struct sec_ctx *ctx)
sec = container_of(ctx->qps[0]->q
[PATCH v4 0/3] crypto:hisilicon/sec - fixes some coding style
1. Fix a problems. 2. Fix some coding style. Changes v3 -> v4: - Fixed an unused warning on dev. - Create a patch for bugfix Changes v2 -> v3: - Delete shash test error patch. Changes v1 -> v2: - Modify the way to fix shash test error. Longfang Liu (3): crypto: hisilicon/sec - fixes a printing error crypto: hisilicon/sec - fixes some coding style crypto: hisilicon/sec - fixes some driver coding style drivers/crypto/hisilicon/sec2/sec.h| 5 +- drivers/crypto/hisilicon/sec2/sec_crypto.c | 77 + drivers/crypto/hisilicon/sec2/sec_crypto.h | 2 - drivers/crypto/hisilicon/sec2/sec_main.c | 131 + 4 files changed, 116 insertions(+), 99 deletions(-) -- 2.8.1
[v4] PCI: Add reset quirk for Huawei Intelligent NIC virtual function
When multiple VFs do FLR at the same time, the firmware is
processed serially, resulting in some VF FLRs being delayed more
than 100ms, when the virtual machine restarts and the device
driver is loaded, the firmware is doing the corresponding VF
FLR, causing the driver to fail to load.
To solve this problem, add host and firmware status synchronization
during FLR.
Signed-off-by: Chiqijun
---
v4:
- Addressed Bjorn's review comments
v3:
- The MSE bit in the VF configuration space is hardwired to zero,
remove the setting of PCI_COMMAND_MEMORY bit. Add comment for
set PCI_COMMAND register.
v2:
- Update comments
- Use the HINIC_VF_FLR_CAP_BIT_SHIFT and HINIC_VF_FLR_PROC_BIT_SHIFT
macro instead of the magic number
---
drivers/pci/quirks.c | 69
1 file changed, 69 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 653660e3ba9e..4623125098e0 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3913,6 +3913,73 @@ static int delay_250ms_after_flr(struct pci_dev *dev,
int probe)
return 0;
}
+#define PCI_DEVICE_ID_HINIC_VF 0x375E
+#define HINIC_VF_FLR_TYPE 0x1000
+#define HINIC_VF_FLR_CAP_BIT_SHIFT 30
+#define HINIC_VF_OP 0xE80
+#define HINIC_VF_FLR_PROC_BIT_SHIFT 18
+#define HINIC_OPERATION_TIMEOUT 15000 /* 15 seconds */
+
+/* Device-specific reset method for Huawei Intelligent NIC virtual functions */
+static int reset_hinic_vf_dev(struct pci_dev *pdev, int probe)
+{
+ unsigned long timeout;
+ void __iomem *bar;
+ u32 val;
+
+ if (probe)
+ return 0;
+
+ bar = pci_iomap(pdev, 0, 0);
+ if (!bar)
+ return -ENOTTY;
+
+ /* Get and check firmware capabilities. */
+ val = be32_to_cpu(readl(bar + HINIC_VF_FLR_TYPE));
+ if (!(val & (1UL << HINIC_VF_FLR_CAP_BIT_SHIFT))) {
+ pci_iounmap(pdev, bar);
+ return -ENOTTY;
+ }
+
+ /*
+* Set the processing bit for the start of FLR, which will be cleared
+* by the firmware after FLR is completed.
+*/
+ val = be32_to_cpu(readl(bar + HINIC_VF_OP));
+ val = val | (1UL << HINIC_VF_FLR_PROC_BIT_SHIFT);
+ writel(cpu_to_be32(val), bar + HINIC_VF_OP);
+
+ /* Perform the actual device function reset */
+ pcie_flr(pdev);
+
+ /*
+* The device must learn BDF after FLR in order to respond to BAR's
+* read request, therefore, we issue a configure write request to let
+* the device capture BDF.
+*/
+ pci_write_config_word(pdev, PCI_VENDOR_ID, 0);
+
+ /* Waiting for device reset complete */
+ timeout = jiffies + msecs_to_jiffies(HINIC_OPERATION_TIMEOUT);
+ do {
+ val = be32_to_cpu(readl(bar + HINIC_VF_OP));
+ if (!(val & (1UL << HINIC_VF_FLR_PROC_BIT_SHIFT)))
+ goto reset_complete;
+ msleep(20);
+ } while (time_before(jiffies, timeout));
+
+ val = be32_to_cpu(readl(bar + HINIC_VF_OP));
+ if (!(val & (1UL << HINIC_VF_FLR_PROC_BIT_SHIFT)))
+ goto reset_complete;
+
+ pci_warn(pdev, "Reset dev timeout, flr ack reg: %#010x\n", val);
+
+reset_complete:
+ pci_iounmap(pdev, bar);
+
+ return 0;
+}
+
static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
reset_intel_82599_sfp_virtfn },
@@ -3924,6 +3991,8 @@ static const struct pci_dev_reset_methods
pci_dev_reset_methods[] = {
{ PCI_VENDOR_ID_INTEL, 0x0953, delay_250ms_after_flr },
{ PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
reset_chelsio_generic_dev },
+ { PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
+ reset_hinic_vf_dev },
{ 0 }
};
--
2.17.1
Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail
On Fri, Mar 12, 2021 at 9:12 PM Ben Dooks wrote:
>
> On 12/03/2021 16:25, Alex Ghiti wrote:
> >
> >
> > Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit :
> >> On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks
> >> wrote:
> >>>
> >>> On 10/03/2021 17:16, Dmitry Vyukov wrote:
> On Wed, Mar 10, 2021 at 5:46 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:0d7588ab riscv: process: Fix no prototype for
> > arch_dup_tas..
> > git tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
> > console output:
> > https://syzkaller.appspot.com/x/log.txt?x=1212c6e6d0
> > kernel config:
> > https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
> > dashboard link:
> > https://syzkaller.appspot.com/bug?extid=e74b94fe601ab9552d69
> > userspace arch: riscv64
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to
> > the commit:
> > Reported-by: syzbot+e74b94fe601ab9552...@syzkaller.appspotmail.com
>
> +riscv maintainers
>
> This is riscv64-specific.
> I've seen similar crashes in put_user in other places. It looks like
> put_user crashes in the user address is not mapped/protected (?).
> >>>
> >>> I've been having a look, and this seems to be down to access of the
> >>> tsk->set_child_tid variable. I assume the fuzzing here is to pass a
> >>> bad address to clone?
> >>>
> >>> From looking at the code, the put_user() code should have set the
> >>> relevant SR_SUM bit (the value for this, which is 1<<18 is in the
> >>> s2 register in the crash report) and from looking at the compiler
> >>> output from my gcc-10, the code looks to be dong the relevant csrs
> >>> and then csrc around the put_user
> >>>
> >>> So currently I do not understand how the above could have happened
> >>> over than something re-tried the code seqeunce and ended up retrying
> >>> the faulting instruction without the SR_SUM bit set.
> >>
> >> I would maybe blame qemu for randomly resetting SR_SUM, but it's
> >> strange that 99% of these crashes are in schedule_tail. If it would be
> >> qemu, then they would be more evenly distributed...
> >>
> >> Another observation: looking at a dozen of crash logs, in none of
> >> these cases fuzzer was actually trying to fuzz clone with some insane
> >> arguments. So it looks like completely normal clone's (e..g coming
> >> from pthread_create) result in this crash.
> >>
> >> I also wonder why there is ret_from_exception, is it normal? I see
> >> handle_exception disables SR_SUM:
> >
> > csrrc does the right thing: it cleans SR_SUM bit in status but saves the
> > previous value that will get correctly restored.
> >
> > ("The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the
> > value of the CSR, zero-extends the value to XLEN bits, and writes it to
> > integer registerrd. The initial value in integerregisterrs1is treated
> > as a bit mask that specifies bit positions to be cleared in the CSR. Any
> > bitthat is high inrs1will cause the corresponding bit to be cleared in
> > the CSR, if that CSR bit iswritable. Other bits in the CSR are
> > unaffected.")
>
> I think there may also be an understanding issue on what the SR_SUM
> bit does. I thought if it is set, M->U accesses would fault, which is
> why it gets set early on. But from reading the uaccess code it looks
> like the uaccess code sets it on entry and then clears on exit.
>
> I am very confused. Is there a master reference for rv64?
>
> https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.pdf
> seems to state PUM is the SR_SUM bit, and that (if set) disabled
>
> Quote:
> The PUM (Protect User Memory) bit modifies the privilege with which
> S-mode loads, stores, and instruction fetches access virtual memory.
> When PUM=0, translation and protection behave as normal. When PUM=1,
> S-mode memory accesses to pages that are accessible by U-mode (U=1 in
> Figure 4.19) will fault. PUM has no effect when executing in U-mode
>
>
> >> https://elixir.bootlin.com/linux/v5.12-rc2/source/arch/riscv/kernel/entry.S#L73
> >>
> >
> > Still no luck for the moment, can't reproduce it locally, my test is
> > maybe not that good (I created threads all day long in order to trigger
> > the put_user of schedule_tail).
>
> It may of course depend on memory and other stuff. I did try to see if
> it was possible to clone() with the child_tid address being a valid but
> not mapped page...
>
> > Given that the path you mention works most of the time, and that the
> > status register in the stack trace shows the SUM bit is not set whereas
> > it is set in put_user, I'm leaning toward some race condition (maybe an
> > interrupt that arrives at the "wrong" time) or a qemu issue as you
> > mentioned.
>
> I suppose this is possible. From what I read it should get to the
>
Re: [PATCH V3 XRT Alveo 17/18] fpga: xrt: partition isolation platform driver
Hi Tom,
On 03/06/2021 07:54 AM, Tom Rix wrote:
On 2/17/21 10:40 PM, Lizhi Hou wrote:
Add partition isolation platform driver. partition isolation is
a hardware function discovered by walking firmware metadata.
A platform device node will be created for it. Partition isolation
function isolate the different fpga regions
Signed-off-by: Sonal Santan
Signed-off-by: Max Zhen
Signed-off-by: Lizhi Hou
---
drivers/fpga/xrt/include/xleaf/axigate.h | 25 ++
drivers/fpga/xrt/lib/xleaf/axigate.c | 298 +++
2 files changed, 323 insertions(+)
create mode 100644 drivers/fpga/xrt/include/xleaf/axigate.h
create mode 100644 drivers/fpga/xrt/lib/xleaf/axigate.c
diff --git a/drivers/fpga/xrt/include/xleaf/axigate.h
b/drivers/fpga/xrt/include/xleaf/axigate.h
new file mode 100644
index ..2cef71e13b30
--- /dev/null
+++ b/drivers/fpga/xrt/include/xleaf/axigate.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header file for XRT Axigate Leaf Driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou
+ */
+
+#ifndef _XRT_AXIGATE_H_
+#define _XRT_AXIGATE_H_
+
+#include "xleaf.h"
+#include "metadata.h"
+
+/*
+ * AXIGATE driver IOCTL calls.
+ */
+enum xrt_axigate_ioctl_cmd {
+ XRT_AXIGATE_FREEZE = XRT_XLEAF_CUSTOM_BASE, /* See comments in xleaf.h */
+ XRT_AXIGATE_FREE,
These are substrings, could change suffix to make it harder for developer to
mix up.
Will change 'freeze' to 'close', 'free' to 'open'.
+};
+
+#endif /* _XRT_AXIGATE_H_ */
diff --git a/drivers/fpga/xrt/lib/xleaf/axigate.c
b/drivers/fpga/xrt/lib/xleaf/axigate.c
new file mode 100644
index ..382969f9925f
--- /dev/null
+++ b/drivers/fpga/xrt/lib/xleaf/axigate.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo FPGA AXI Gate Driver
+ *
+ * Copyright (C) 2020-2021 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "metadata.h"
+#include "xleaf.h"
+#include "xleaf/axigate.h"
+
+#define XRT_AXIGATE "xrt_axigate"
+
+struct axigate_regs {
+ u32 iag_wr;
+ u32 iag_rvsd;
+ u32 iag_rd;
+} __packed;
similar to other patches, prefix of element is not needed.
Will remove this and use #define and regmap.
+
+struct xrt_axigate {
+ struct platform_device *pdev;
+ void*base;
+ struct mutexgate_lock; /* gate dev lock */
+
+ void*evt_hdl;
+ const char *ep_name;
+
+ boolgate_freezed;
+};
+
+/* the ep names are in the order of hardware layers */
+static const char * const xrt_axigate_epnames[] = {
+ XRT_MD_NODE_GATE_PLP,
+ XRT_MD_NODE_GATE_ULP,
what are plp, ulp ? it is helpful to comment or expand acronyms
plp stands for provider logic partition and ulp stands for user logic
partition. Will add comment.
+ NULL
+};
+
+#define reg_rd(g, r) \
+ ioread32((void *)(g)->base + offsetof(struct axigate_regs, r))
+#define reg_wr(g, v, r) \
+ iowrite32(v, (void *)(g)->base + offsetof(struct axigate_regs, r))
+
+static inline void freeze_gate(struct xrt_axigate *gate)
+{
+ reg_wr(gate, 0, iag_wr);
The values written here and below are magic, the need to have #defines
Will add #defines
+ ndelay(500);
+ reg_rd(gate, iag_rd);
+}
+
+static inline void free_gate(struct xrt_axigate *gate)
+{
+ reg_wr(gate, 0x2, iag_wr);
+ ndelay(500);
+ (void)reg_rd(gate, iag_rd);
+ reg_wr(gate, 0x3, iag_wr);
+ ndelay(500);
+ reg_rd(gate, iag_rd);
+}
+
+static int xrt_axigate_epname_idx(struct platform_device *pdev)
+{
+ int i;
+ int ret;
int i, ret;
sure.
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ xrt_err(pdev, "Empty Resource!");
+ return -EINVAL;
+ }
+
+ for (i = 0; xrt_axigate_epnames[i]; i++) {
null guarded array is useful with the size isn't know,
in this case it is, so covert loop to using ARRAY_SIZE
Will use ARRAY_SIZE.
+ ret = strncmp(xrt_axigate_epnames[i], res->name,
+ strlen(xrt_axigate_epnames[i]) + 1);
needs a strlen check in case res->name is just a substring
'strlen() + 1' is used, thus the comparing covers substring as well.
+ if (!ret)
+ break;
+ }
+
+ ret = (xrt_axigate_epnames[i]) ? i : -EINVAL;
+ return ret;
+}
+
+static void xrt_axigate_freeze(struct platform_device *pdev)
+{
+ struct xrt_axigate *gate;
+ u32 freeze = 0;
+
+ gate = platform_get_drvdata(pdev);
+
+ mutex_lock(&gate->gate_lock);
+ freeze = reg_rd(gate, iag_rd);
+ if (freeze) { /* gate is opened */
+ xle
Re: [PATCH] docs: admin-guide: cgroup-v1: Fix typos in the file memory.rst
On 3/12/21 10:10 PM, Bhaskar Chowdhury wrote: > > s/overcommited/overcommitted/ > s/Overcommiting/Overcommitting/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > Documentation/admin-guide/cgroup-v1/memory.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst > b/Documentation/admin-guide/cgroup-v1/memory.rst > index 52688ae34461..0d574fd3f8e3 100644 > --- a/Documentation/admin-guide/cgroup-v1/memory.rst > +++ b/Documentation/admin-guide/cgroup-v1/memory.rst > @@ -360,8 +360,8 @@ U != 0, K = unlimited: > > U != 0, K < U: > Kernel memory is a subset of the user memory. This setup is useful in > -deployments where the total amount of memory per-cgroup is overcommited. > -Overcommiting kernel memory limits is definitely not recommended, since > the > +deployments where the total amount of memory per-cgroup is overcommitted. > +Overcommitting kernel memory limits is definitely not recommended, since > the > box can still run out of non-reclaimable memory. > In this case, the admin could set up K so that the sum of all groups is > never greater than the total memory, and freely set U at the cost of his > -- -- ~Randy
Re: [PATCH] net: ethernet: marvell: Fixed typo in the file sky2.c
On 3/12/21 9:45 PM, Bhaskar Chowdhury wrote:
>
> s/calclation/calculation/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
Subject: should say "Fix typo", not "Fixed typo".
> ---
> drivers/net/ethernet/marvell/sky2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/sky2.c
> b/drivers/net/ethernet/marvell/sky2.c
> index ebe1406c6e64..18a3db2fd337 100644
> --- a/drivers/net/ethernet/marvell/sky2.c
> +++ b/drivers/net/ethernet/marvell/sky2.c
> @@ -4135,7 +4135,7 @@ static int sky2_set_coalesce(struct net_device *dev,
> /*
> * Hardware is limited to min of 128 and max of 2048 for ring size
> * and rounded up to next power of two
> - * to avoid division in modulus calclation
> + * to avoid division in modulus calculation
> */
> static unsigned long roundup_ring_size(unsigned long pending)
> {
> --
--
~Randy
Re: [PATCH] clk: at91: Trivial typo fixes in the file sama7g5.c
On 3/12/21 9:32 PM, Bhaskar Chowdhury wrote:
>
> s/critial/critical/ ..two different places
> s/parrent/parent/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/clk/at91/sama7g5.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
> index a6e20b35960e..9e1ec48c4474 100644
> --- a/drivers/clk/at91/sama7g5.c
> +++ b/drivers/clk/at91/sama7g5.c
> @@ -166,7 +166,7 @@ static const struct {
> .c = &pll_characteristics,
> .t = PLL_TYPE_FRAC,
> /*
> - * This feeds syspll_divpmcck which may feed critial parts
> + * This feeds syspll_divpmcck which may feed critical parts
> * of the systems like timers. Therefore it should not be
> * disabled.
> */
> @@ -178,7 +178,7 @@ static const struct {
> .c = &pll_characteristics,
> .t = PLL_TYPE_DIV,
> /*
> - * This may feed critial parts of the systems like timers.
> + * This may feed critical parts of the systems like timers.
> * Therefore it should not be disabled.
> */
> .f = CLK_IS_CRITICAL | CLK_SET_RATE_GATE,
> @@ -455,7 +455,7 @@ static const struct {
> * @pp: PLL parents
> * @pp_mux_table:PLL parents mux table
> * @r: clock output range
> - * @pp_chg_id: id in parrent array of changeable PLL parent
> + * @pp_chg_id: id in parent array of changeable PLL parent
> * @pp_count:PLL parents count
> * @id: clock id
> */
> --
--
~Randy
Re: [PATCH 07/11] PM / devfreq: check get_dev_status before start monitor
On Sat, Mar 13, 2021 at 12:09 AM Chanwoo Choi wrote:
>
> On 21. 3. 12. 오후 7:57, Dong Aisheng wrote:
> > On Thu, Mar 11, 2021 at 2:54 PM Chanwoo Choi wrote:
> >>
> >> On 3/10/21 1:56 PM, Dong Aisheng wrote:
> >>> On Wed, Mar 10, 2021 at 11:08 AM Chanwoo Choi
> >>> wrote:
>
> On 3/10/21 11:56 AM, Dong Aisheng wrote:
> > On Wed, Mar 10, 2021 at 12:12 AM Chanwoo Choi
> > wrote:
> >>
> >> On 21. 3. 10. 오전 12:58, Chanwoo Choi wrote:
> >>> On 21. 3. 9. 오후 9:58, Dong Aisheng wrote:
> The devfreq monitor depends on the device to provide load information
> by .get_dev_status() to calculate the next target freq.
>
> And this will cause changing governor to simple ondemand fail
> if device can't support.
>
> Signed-off-by: Dong Aisheng
> ---
> drivers/devfreq/devfreq.c | 10 +++---
> drivers/devfreq/governor.h| 2 +-
> drivers/devfreq/governor_simpleondemand.c | 3 +--
> 3 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 7231fe6862a2..d1787b6c7d7c 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -482,10 +482,13 @@ static void devfreq_monitor(struct work_struct
> *work)
> * to be called from governor in response to DEVFREQ_GOV_START
> * event when device is added to devfreq framework.
> */
> -void devfreq_monitor_start(struct devfreq *devfreq)
> +int devfreq_monitor_start(struct devfreq *devfreq)
> {
> if (IS_SUPPORTED_FLAG(devfreq->governor->flags, IRQ_DRIVEN))
> -return;
> +return 0;
> +
> +if (!devfreq->profile->get_dev_status)
> +return -EINVAL;
> >>
> >> Again, I think that get_dev_status is not used for all governors.
> >> So that it cause the governor start fail. Don't check whether
> >> .get_dev_status is NULL or not.
> >>
> >
> > I'm not quite understand your point.
> > it is used by governor_simpleondemand.c and tegra_devfreq_governor.
> > get_target_freq -> devfreq_update_stats -> get_dev_status
>
> The devfreq can add the new governor by anyone.
> So these functions like devfreq_monitor_* have to support
> the governors and also must support the governor to be added
> in the future.
> >>>
> >>> Yes, but devfreq_monitor_* is only used by polling mode, right?
> >>> The governor using it has to implement get_dev_status unless
> >>> there's an exception in the future.
> >>>
> >>> Currently this patch wants to address the issue that user can switch
> >>> to ondemand governor (polling mode) by sysfs even devices does
> >>> not support it (no get_dev_status implemented).
> >>
> >> As I commented, I'll fix this issue. If devfreq driver doesn't implement
> >> the .get_dev_status, don't show it via available_governors. I think that
> >> it is fundamental solution to fix this issue.
> >
> > Sounds good
> >
> >> So on this version,
> >> don't add the this conditional statement on this function
> >>
> >
> > Almost all this patch did is adding a checking for get_dev_status.
> > So do you mean drop this patch?
> > I wonder it's still a necessary checking to explicitly tell devfreq monitor
> > users that get_dev_status is needed during governor startup.
>
> I think that the it is enough to check .get_dev_status in
> devfreq_update_stats. We have to check it on where it is used.
>
I think the drawback of only checking .get_dev_status in
devfreq_update_stats is:
1. devfreq will still register successfully and ondemand governor starts ok
2. ondemand governor will still be shown in sysfs which is something
you want to fix
3. devfreq will end up printing endless error messages in devfreq_monitor worker
"dvfs failed with (%d) error" as the possible missing .get_dev_status
So i wonder if you don't like changing the common devfreq_monitor_start in order
to make it look common for all governors, then we probably still need
to fix it in
ondemand governor in order to avoid the possible above issues.
static int devfreq_simple_ondemand_handler(struct devfreq *devfreq,
unsigned int event, void *data)
{
switch (event) {
case DEVFREQ_GOV_START:
if (!devfreq->profile->get_dev_status)
return -EINVAL;
return devfreq_monitor_start(devfreq);
...
}
How do you think?
Regards
Aisheng
> >
> >> And on next version, please use the capital letter for first character
> >> on patch title as following:
> >>
> >> - PM / devfreq: Check get_dev_status before start monitor
> >>
> >
> > Okay to me.
> > Thanks for the suggestion.
> >
> > Regards
> > Aisheng
> >
> >>>
> >>> R
arch/arm64/kvm/sys_regs.c:165 vcpu_write_sys_reg() warn: inconsistent indenting
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f296bfd5cd04cbb49b8fc9585adc280ab2b58624
commit: 7ea90bdd70c9cf82dfbaa54e7d9f296928679224 KVM: arm64: Refactor
vcpu_{read,write}_sys_reg
date: 10 months ago
config: arm64-randconfig-m031-20210312 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
arch/arm64/kvm/sys_regs.c:165 vcpu_write_sys_reg() warn: inconsistent indenting
vim +165 arch/arm64/kvm/sys_regs.c
7ea90bdd70c9cf Marc Zyngier 2019-06-20 158
7ea90bdd70c9cf Marc Zyngier 2019-06-20 159 void vcpu_write_sys_reg(struct
kvm_vcpu *vcpu, u64 val, int reg)
7ea90bdd70c9cf Marc Zyngier 2019-06-20 160 {
7ea90bdd70c9cf Marc Zyngier 2019-06-20 161 if
(vcpu->arch.sysregs_loaded_on_cpu &&
7ea90bdd70c9cf Marc Zyngier 2019-06-20 162
__vcpu_write_sys_reg_to_cpu(val, reg))
7ea90bdd70c9cf Marc Zyngier 2019-06-20 163 return;
7ea90bdd70c9cf Marc Zyngier 2019-06-20 164
d47533dab9f50e Christoffer Dall 2017-12-23 @165 __vcpu_sys_reg(vcpu,
reg) = val;
d47533dab9f50e Christoffer Dall 2017-12-23 166 }
d47533dab9f50e Christoffer Dall 2017-12-23 167
:: The code at line 165 was first introduced by commit
:: d47533dab9f50eeb7289a38035c39c9eadb1e048 KVM: arm64: Introduce framework
for accessing deferred sysregs
:: TO: Christoffer Dall
:: CC: Marc Zyngier
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] include: linux: Fix a typo in the file fs.h
On 23:06 Fri 12 Mar 2021, Tom Saeger wrote: On Sat, Mar 13, 2021 at 10:49:55AM +0530, Bhaskar Chowdhury wrote: s/varous/various/ Signed-off-by: Bhaskar Chowdhury --- include/linux/fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index ec8f3ddf4a6a..c37a17c32d74 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1051,7 +1051,7 @@ bool opens_in_grace(struct net *); * FIXME: should we create a separate "struct lock_request" to help distinguish * these two uses? * - * The varous i_flctx lists are ordered by: + * The various i_flctx lists are ordered by: * * 1) lock owner * 2) lock range start -- 2.26.2 How about a few more? found by running: codespell -w -i 3 include/linux/fs.h Never bother to use that tool...not sure ... 'specialy' could be 'special' or 'specialty' it can be dropped altogether IMO, so I did. --Tom diff --git a/include/linux/fs.h b/include/linux/fs.h index c37a17c32d74..9ffea695a059 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -126,7 +126,7 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, /* File is opened with O_EXCL (only set for block devices) */ #define FMODE_EXCL ((__force fmode_t)0x80) /* File is opened using open(.., 3, ..) and is writeable only for ioctls - (specialy hack for floppy.c) */ + (hack for floppy.c) */ #define FMODE_WRITE_IOCTL ((__force fmode_t)0x100) /* 32bit hashes as llseek() offset (for directories) */ #define FMODE_32BITHASH ((__force fmode_t)0x200) @@ -819,7 +819,7 @@ void lock_two_nondirectories(struct inode *, struct inode*); void unlock_two_nondirectories(struct inode *, struct inode*); /* - * NOTE: in a 32bit arch with a preemptable kernel and + * NOTE: in a 32bit arch with a preemptible kernel and * an UP compile the i_size_read/write must be atomic * with respect to the local cpu (unlike with preempt disabled), * but they don't need to be atomic with respect to other cpus like in signature.asc Description: PGP signature
[PATCH] docs: admin-guide: cgroup-v1: Fix typos in the file memory.rst
s/overcommited/overcommitted/ s/Overcommiting/Overcommitting/ Signed-off-by: Bhaskar Chowdhury --- Documentation/admin-guide/cgroup-v1/memory.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 52688ae34461..0d574fd3f8e3 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -360,8 +360,8 @@ U != 0, K = unlimited: U != 0, K < U: Kernel memory is a subset of the user memory. This setup is useful in -deployments where the total amount of memory per-cgroup is overcommited. -Overcommiting kernel memory limits is definitely not recommended, since the +deployments where the total amount of memory per-cgroup is overcommitted. +Overcommitting kernel memory limits is definitely not recommended, since the box can still run out of non-reclaimable memory. In this case, the admin could set up K so that the sum of all groups is never greater than the total memory, and freely set U at the cost of his -- 2.26.2
Re: [PATCH] include: linux: Fix a typo in the file fs.h
On Sat, Mar 13, 2021 at 10:49:55AM +0530, Bhaskar Chowdhury wrote: > s/varous/various/ > > Signed-off-by: Bhaskar Chowdhury > --- > include/linux/fs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index ec8f3ddf4a6a..c37a17c32d74 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1051,7 +1051,7 @@ bool opens_in_grace(struct net *); > * FIXME: should we create a separate "struct lock_request" to help > distinguish > * these two uses? > * > - * The varous i_flctx lists are ordered by: > + * The various i_flctx lists are ordered by: > * > * 1) lock owner > * 2) lock range start > -- > 2.26.2 > How about a few more? found by running: codespell -w -i 3 include/linux/fs.h 'specialy' could be 'special' or 'specialty' it can be dropped altogether IMO, so I did. --Tom diff --git a/include/linux/fs.h b/include/linux/fs.h index c37a17c32d74..9ffea695a059 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -126,7 +126,7 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, /* File is opened with O_EXCL (only set for block devices) */ #define FMODE_EXCL ((__force fmode_t)0x80) /* File is opened using open(.., 3, ..) and is writeable only for ioctls - (specialy hack for floppy.c) */ + (hack for floppy.c) */ #define FMODE_WRITE_IOCTL ((__force fmode_t)0x100) /* 32bit hashes as llseek() offset (for directories) */ #define FMODE_32BITHASH ((__force fmode_t)0x200) @@ -819,7 +819,7 @@ void lock_two_nondirectories(struct inode *, struct inode*); void unlock_two_nondirectories(struct inode *, struct inode*); /* - * NOTE: in a 32bit arch with a preemptable kernel and + * NOTE: in a 32bit arch with a preemptible kernel and * an UP compile the i_size_read/write must be atomic * with respect to the local cpu (unlike with preempt disabled), * but they don't need to be atomic with respect to other cpus like in
[PATCH v3] perf tools: perf_event_paranoid and kptr_restrict may crash on 'perf top'
After install the libelf-dev package and compiling perf, kptr_restrict=2
and perf_event_paranoid=3 will cause perf top to crash, because the
value of /proc/kallsyms cannot be obtained, which leads to
info->jited_ksyms == NULL. In order to solve this problem, Add a
judgment before use.
V2->V3:
free info_linear memory and move code above, don't do those extra btf
checks.
Suggested-by: Jiri Olsa
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Namhyung Kim
Signed-off-by: Jackie Liu
---
tools/perf/util/bpf-event.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 57d58c81a5f8..3c03c782bac6 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -201,12 +201,18 @@ static int perf_event__synthesize_one_bpf_prog(struct
perf_session *session,
}
info = &info_linear->info;
+ if (!info->jited_ksyms) {
+ free(info_linear);
+ return -1;
+ }
/* number of ksyms, func_lengths, and tags should match */
sub_prog_cnt = info->nr_jited_ksyms;
if (sub_prog_cnt != info->nr_prog_tags ||
- sub_prog_cnt != info->nr_jited_func_lens)
+ sub_prog_cnt != info->nr_jited_func_lens) {
+ free(info_linear);
return -1;
+ }
/* check BTF func info support */
if (info->btf_id && info->nr_func_info && info->func_info_rec_size) {
--
2.25.1
Re: [PATCH] iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
On Sat, Mar 13, 2021 at 6:45 AM Kalle Valo wrote: > > Jiri Kosina writes: > > > On Mon, 8 Mar 2021, Jiri Kosina wrote: > > > >> > From: Jiri Kosina > >> > > >> > It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs > >> > disabled (e.g. from LED core). We can't enable BHs in such a situation. > >> > > >> > Turn the unconditional BH-enable/BH-disable code into > >> > hardirq-disable/conditional-enable. > >> > > >> > This fixes the warning below. > >> > >> Hi, > >> > >> friendly ping on this one ... > > > > Luca, > > > > Johannes is telling me that he merged this patch internally, but I have no > > idea what is happening to it ... ? > > > > The reported splat is a clear bug, so it should be fixed one way or the > > other. > > Should I take this to wireless-drivers? > If you do so, please add: Tested-by: Sedat Dilek # LLVM/Clang v12.0.0-rc3 - Sedat - > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v5 0/3] x86/bus_lock: Enable bus lock detection
A bus lock [1] is acquired through either split locked access to writeback (WB) memory or any locked access to non-WB memory. This is typically >1000 cycles slower than an atomic operation within a cache line. It also disrupts performance on other cores. Although split lock can be detected by #AC trap, the trap is triggered before the instruction acquires bus lock. This makes it difficult to mitigate bus lock (e.g. throttle the user application). Some CPUs have ability to notify the kernel by an #DB trap after a user instruction acquires a bus lock and is executed. This allows the kernel to enforce user application throttling or mitigations. #DB for bus lock detect fixes issues in #AC for split lock detect: 1) It's architectural ... just need to look at one CPUID bit to know it exists 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread. So each process or guest can have different behavior. 3) It has support for VMM/guests (new VMEXIT codes, etc). 4) It detects not only split locks but also bus locks from non-WB. Hardware only generates #DB for bus lock detect when CPL>0 to avoid nested #DB from multiple bus locks while the first #DB is being handled. Use the existing kernel command line parameter "split_lock_detect=" to handle #DB for bus lock with an additional option "ratelimit=N" to set bus lock rate limit for a user. [1] Intel Instruction Set Extension Chapter 9: https://software.intel.com/content/dam/develop/public/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf Change Log: v5: Address all comments from Thomas: - In the cover letter, update the latest ISE link to include the #DB for bus lock spec. - In patch 1, add commit message for breakpoint and bus lock on the same instruction. - In patch 2, change warn to #AC if both #AC and #DB are supported, remove sld and bld variables, remove bus lock checking in handle_bus_lock() etc. - In patch 3 and 4, remove bld_ratelimit < HZ/2 check and define bld_ratelimit only for Intel CPUs. - Merge patch 2 and 3 into one patch for handling warn, fatal, and ratelimit. v4 is here: https://lore.kernel.org/lkml/20201124205245.4164633-2-fenghua...@intel.com/ v4: - Fix a ratelimit wording issue in the doc (Randy). - Patch 4 is acked by Randy (Randy). v3: - Enable Bus Lock Detection when fatal to handle bus lock from non-WB (PeterZ). - Add Acked-by: PeterZ in patch 2. v2: - Send SIGBUS in fatal case for bus lock #DB (PeterZ). v1: - Check bus lock bit by its positive polarity (Xiaoyao). - Fix a few wording issues in the documentation (Randy). [RFC v3 can be found at: https://lore.kernel.org/patchwork/cover/1329943/] RFC v3: - Remove DR6_RESERVED change (PeterZ). - Simplify the documentation (Randy). RFC v2: - Architecture changed based on feedback from Thomas and PeterZ. #DB is no longer generated for bus lock in ring0. - Split the one single patch into four patches. [RFC v1 can be found at: https://lore.kernel.org/lkml/1595021700-68460-1-git-send-email-fenghua...@intel.com/] Fenghua Yu (3): x86/cpufeatures: Enumerate #DB for bus lock detection x86/bus_lock: Handle #DB for bus lock Documentation/admin-guide: Change doc for split_lock_detect parameter .../admin-guide/kernel-parameters.txt | 30 +++- arch/x86/include/asm/cpu.h| 10 +- arch/x86/include/asm/cpufeatures.h| 1 + arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/uapi/asm/debugreg.h | 1 + arch/x86/kernel/cpu/common.c | 2 +- arch/x86/kernel/cpu/intel.c | 148 +++--- arch/x86/kernel/traps.c | 7 + include/linux/sched/user.h| 5 +- kernel/user.c | 13 ++ 10 files changed, 187 insertions(+), 31 deletions(-) -- 2.30.2
[PATCH v5 2/3] x86/bus_lock: Handle #DB for bus lock
Bus locks degrade performance for the whole system, not just for the CPU
that requested the bus lock. Two CPU features "#AC for split lock" and
"#DB for bus lock" provide hooks so that the operating system may choose
one of several mitigation strategies.
#AC for split lock is already implemented. Add code to use the #DB for
bus lock feature to cover additional situations with new options to
mitigate.
split_lock_detect=
#AC for split lock #DB for bus lock
off Do nothing Do nothing
warnKernel OOPs Warn once per task and
Warn once per task and and continues to run.
disable future checking
When both features are
supported, warn in #AC
fatal Kernel OOPs Send SIGBUS to user.
Send SIGBUS to user
When both features are
supported, fatal in #AC
ratelimit:N Do nothing Limit bus lock rate to
N per second in the
current non-root user.
Default option is "warn".
Hardware only generates #DB for bus lock detect when CPL>0 to avoid
nested #DB from multiple bus locks while the first #DB is being handled.
So no need to handle #DB for bus lock detected in the kernel.
#DB for bus lock is enabled by bus lock detection bit 2 in DEBUGCTL MSR
while #AC for split lock is enabled by split lock detection bit 29 in
TEST_CTRL MSR.
Both breakpoint and bus lock in the same instruction can trigger one #DB.
The bus lock is handled before the breakpoint in the #DB handler.
Delivery of #DB for bus lock in userspace clears DR6[11]. To avoid
confusion in identifying #DB, #DB handler sets the bit to 1 before
returning to the interrupted task.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
Change Log:
v5:
Address all comments from Thomas:
- Merge patch 2 and patch 3 into one patch so all "split_lock_detect="
options are processed in one patch.
- Change warn to #AC if both #AC and #DB are supported.
- Remove sld and bld variables and use boot_cpu_has() to check bus lock
split lock support.
- Remove bus lock checking in handle_bus_lock().
- Remove bld_ratelimit < HZ/2 check.
- Add rate limit handling comment in bus lock #DB.
- Define bld_ratelimit only for Intel CPUs.
v3:
- Enable Bus Lock Detection when fatal to handle bus lock from non-WB
(PeterZ).
v2:
- Send SIGBUS in fatal case for bus lock #DB (PeterZ).
v1::
- Check bus lock bit by its positive polarity (Xiaoyao).
RFC v3:
- Remove DR6_RESERVED change (PeterZ).
arch/x86/include/asm/cpu.h | 10 +-
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/include/uapi/asm/debugreg.h | 1 +
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/intel.c | 148 +++
arch/x86/kernel/traps.c | 7 ++
include/linux/sched/user.h | 5 +-
kernel/user.c| 13 +++
8 files changed, 162 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index da78ccbd493b..991de5f2a09c 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -41,12 +41,14 @@ unsigned int x86_family(unsigned int sig);
unsigned int x86_model(unsigned int sig);
unsigned int x86_stepping(unsigned int sig);
#ifdef CONFIG_CPU_SUP_INTEL
-extern void __init cpu_set_core_cap_bits(struct cpuinfo_x86 *c);
+extern void __init sld_setup(struct cpuinfo_x86 *c);
extern void switch_to_sld(unsigned long tifn);
extern bool handle_user_split_lock(struct pt_regs *regs, long error_code);
extern bool handle_guest_split_lock(unsigned long ip);
+extern void handle_bus_lock(struct pt_regs *regs);
+extern int bld_ratelimit;
#else
-static inline void __init cpu_set_core_cap_bits(struct cpuinfo_x86 *c) {}
+static inline void __init sld_setup(struct cpuinfo_x86 *c) {}
static inline void switch_to_sld(unsigned long tifn) {}
static inline bool handle_user_split_lock(struct pt_regs *regs, long
error_code)
{
@@ -57,6 +59,10 @@ static inline bool handle_guest_split_lock(unsigned long ip)
{
return false;
}
+
+static inline void handle_bus_lock(struct pt_regs *regs)
+{
+}
#endif
#ifdef CONFIG_IA32_FEAT_CTL
void init_ia32_feat_ctl(struct cpuinfo_x86 *c);
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 546d6ecf0a35..558485965f21 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -265,6 +265,7 @@
#define DEBUGCTLMSR_LBR(1UL << 0) /* last branch
recording */
#define DEBUGCTLMSR_BTF_SHIFT 1
#define DEBUGCTLMSR_BTF(1UL << 1) /* single-step on
branches */
+#define DEBUGCTLMSR_BUS_LOCK_DETECT(1UL << 2) /* Bus lock detect */
#define DEBUGCTLMSR_TR
[PATCH v5 3/3] Documentation/admin-guide: Change doc for split_lock_detect parameter
Since #DB for bus lock detect changes the split_lock_detect parameter, update the documentation for the changes. Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck Acked-by: Randy Dunlap --- Change Log: v5: - Remove N < HZ/2 check info in the doc (Thomas). v4: - Fix a ratelimit wording issue in the doc (Randy). - Patch 4 is acked by Randy (Randy). v3: - Enable Bus Lock Detection when fatal to handle bus lock from non-WB (PeterZ). v1: - Fix a few wording issues (Randy). RFC v2: - Simplify the documentation (Randy). .../admin-guide/kernel-parameters.txt | 30 +++ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 04545725f187..16b2e1c45d04 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5100,27 +5100,45 @@ spia_peddr= split_lock_detect= - [X86] Enable split lock detection + [X86] Enable split lock detection or bus lock detection When enabled (and if hardware support is present), atomic instructions that access data across cache line - boundaries will result in an alignment check exception. + boundaries will result in an alignment check exception + for split lock detection or a debug exception for + bus lock detection. off - not enabled - warn- the kernel will emit rate limited warnings + warn- the kernel will emit rate-limited warnings about applications triggering the #AC - exception. This mode is the default on CPUs - that supports split lock detection. + exception or the #DB exception. This mode is + the default on CPUs that support split lock + detection or bus lock detection. Default + behavior is by #DB if both features are + enabled in hardware. fatal - the kernel will send SIGBUS to applications - that trigger the #AC exception. + that trigger the #AC exception or the #DB + exception. If both features are enabled in + hardware, split lock triggers #AC and bus + lock from non-WB triggers #DB. + + ratelimit:N - + Set rate limit to N bus locks per second + for bus lock detection. 0 < N. + Only applied to non-root users. + + N/A for split lock detection. If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" mode. + #DB exception for bus lock is triggered only when + CPL > 0. + srbds= [X86,INTEL] Control the Special Register Buffer Data Sampling (SRBDS) mitigation. -- 2.30.2
[PATCH v5 1/3] x86/cpufeatures: Enumerate #DB for bus lock detection
A bus lock is acquired though either split locked access to writeback (WB) memory or any locked access to non-WB memory. This is typically >1000 cycles slower than an atomic operation within a cache line. It also disrupts performance on other cores. Some CPUs have ability to notify the kernel by an #DB trap after a user instruction acquires a bus lock and is executed. This allows the kernel to enforce user application throttling or mitigations. Both breakpoint and bus lock can trigger the #DB trap in the same instruction and the ordering of handling them is the kernel #DB handler's choice. The CPU feature flag to be shown in /proc/cpuinfo will be "bus_lock_detect". Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck --- Change Log: v5: - Add "Both breakpoint and bus lock can trigger an #DB trap..." in the commit message (Thomas). arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index cc96e26d69f7..faec3d92d09b 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -354,6 +354,7 @@ #define X86_FEATURE_AVX512_VPOPCNTDQ (16*32+14) /* POPCNT for vectors of DW/QW */ #define X86_FEATURE_LA57 (16*32+16) /* 5-level page tables */ #define X86_FEATURE_RDPID (16*32+22) /* RDPID instruction */ +#define X86_FEATURE_BUS_LOCK_DETECT(16*32+24) /* Bus Lock detect */ #define X86_FEATURE_CLDEMOTE (16*32+25) /* CLDEMOTE instruction */ #define X86_FEATURE_MOVDIRI(16*32+27) /* MOVDIRI instruction */ #define X86_FEATURE_MOVDIR64B (16*32+28) /* MOVDIR64B instruction */ -- 2.30.2
[PATCH] net: ethernet: marvell: Fixed typo in the file sky2.c
s/calclation/calculation/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/ethernet/marvell/sky2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c
b/drivers/net/ethernet/marvell/sky2.c
index ebe1406c6e64..18a3db2fd337 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -4135,7 +4135,7 @@ static int sky2_set_coalesce(struct net_device *dev,
/*
* Hardware is limited to min of 128 and max of 2048 for ring size
* and rounded up to next power of two
- * to avoid division in modulus calclation
+ * to avoid division in modulus calculation
*/
static unsigned long roundup_ring_size(unsigned long pending)
{
--
2.26.2
[PATCH v6 1/2] arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver
From: Ajit Pandey
Add dai link for supporting lpass I2S driver, which is used
for audio capture and playback.
Add lpass-cpu node with pin controls and i2s primary
and secondary dai-links
Signed-off-by: Ajit Pandey
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 58
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 436582279dad..3a24383247db 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/* PMICs depend on spmi_bus label and so must come after SoC */
#include "pm6150.dtsi"
@@ -283,6 +284,42 @@ keyboard_backlight: keyboard-backlight {
max-brightness = <1023>;
};
};
+
+ sound: sound {
+ compatible = "google,sc7180-trogdor";
+ model = "sc7180-rt5682-max98357a-1mic";
+
+ audio-routing =
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dai-link@0 {
+ link-name = "MultiMedia0";
+ reg = ;
+ cpu {
+ sound-dai = <&lpass_cpu MI2S_PRIMARY>;
+ };
+
+ sound_multimedia0_codec: codec {
+ sound-dai = <&alc5682 0 /*aif1*/>;
+ };
+ };
+
+ dai-link@1 {
+ link-name = "MultiMedia1";
+ reg = ;
+ cpu {
+ sound-dai = <&lpass_cpu MI2S_SECONDARY>;
+ };
+
+ sound_multimedia1_codec: codec {
+ sound-dai = <&max98357a>;
+ };
+ };
+ };
};
&qfprom {
@@ -720,6 +757,27 @@ &ipa {
modem-init;
};
+&lpass_cpu {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sec_mi2s_active &pri_mi2s_active &pri_mi2s_mclk_active>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mi2s-primary@0 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ qcom,capture-sd-lines = <0>;
+ };
+
+ mi2s-secondary@1 {
+ reg = ;
+ qcom,playback-sd-lines = <0>;
+ };
+};
+
&mdp {
status = "okay";
};
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v6 2/2] arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz
This is a trgodor variant, required to have sound node variable
for coachz specific platform.
Signed-off-by: Srinivasa Rao Mandadapu
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
index 4ad520f00485..e2ffe71c2d52 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
@@ -89,6 +89,16 @@ &sn65dsi86_out {
data-lanes = <0 1 2 3>;
};
+&sound {
+ compatible = "google,sc7180-coachz";
+ model = "sc7180-adau7002-max98357a";
+ audio-routing = "PDM_DAT", "DMIC";
+};
+
+&sound_multimedia0_codec {
+ sound-dai = <&adau7002>;
+};
+
/* PINCTRL - modifications to sc7180-trogdor.dtsi */
&en_pp3300_dx_edp {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v6 0/2] Qualcomm's lpass device tree changes for I2s dai
These patches are device tree changes to support audio over I2S. Changes Since v4: -- Removed lpass macro in codec dai cell -- Renamed multimedia dai codec alias name Changes Since v4: -- Removed duplication of dai-link in sound node. -- Replaced reg values with common dt-bindings macros in coachz dtsi -- Included sc7180-lpass.h instead of qcom,lpass.h -- Sound node placement change in coachz dtsi. Changes Since v3: -- Compatible name changed as per trogdor Changes Since v2: -- Sound node variable is added in sc7180-trogdor-coachz.dtsi. -- Audio-jack property is removed, as it may create conflicts with the boards having different codecs. -- Replaced reg values with common dt-bindings macros Changes Since v1: -- Ajith's Certification is added. -- Alias name added for sound dai link node Ajit Pandey (1): arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver Srinivasa Rao Mandadapu (1): arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz .../boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 10 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 58 +++ 2 files changed, 68 insertions(+) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH] clk: at91: Trivial typo fixes in the file sama7g5.c
s/critial/critical/ ..two different places
s/parrent/parent/
Signed-off-by: Bhaskar Chowdhury
---
drivers/clk/at91/sama7g5.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index a6e20b35960e..9e1ec48c4474 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -166,7 +166,7 @@ static const struct {
.c = &pll_characteristics,
.t = PLL_TYPE_FRAC,
/*
- * This feeds syspll_divpmcck which may feed critial parts
+ * This feeds syspll_divpmcck which may feed critical parts
* of the systems like timers. Therefore it should not be
* disabled.
*/
@@ -178,7 +178,7 @@ static const struct {
.c = &pll_characteristics,
.t = PLL_TYPE_DIV,
/*
- * This may feed critial parts of the systems like timers.
+ * This may feed critical parts of the systems like timers.
* Therefore it should not be disabled.
*/
.f = CLK_IS_CRITICAL | CLK_SET_RATE_GATE,
@@ -455,7 +455,7 @@ static const struct {
* @pp:PLL parents
* @pp_mux_table: PLL parents mux table
* @r: clock output range
- * @pp_chg_id: id in parrent array of changeable PLL parent
+ * @pp_chg_id: id in parent array of changeable PLL parent
* @pp_count: PLL parents count
* @id:clock id
*/
--
2.26.2
Re: [PATCH] iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
Jiri Kosina writes: > On Mon, 8 Mar 2021, Jiri Kosina wrote: > >> > From: Jiri Kosina >> > >> > It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs >> > disabled (e.g. from LED core). We can't enable BHs in such a situation. >> > >> > Turn the unconditional BH-enable/BH-disable code into >> > hardirq-disable/conditional-enable. >> > >> > This fixes the warning below. >> >> Hi, >> >> friendly ping on this one ... > > Luca, > > Johannes is telling me that he merged this patch internally, but I have no > idea what is happening to it ... ? > > The reported splat is a clear bug, so it should be fixed one way or the > other. Should I take this to wireless-drivers? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] include: linux: Fix a typo in the file fs.h
s/varous/various/ Signed-off-by: Bhaskar Chowdhury --- include/linux/fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index ec8f3ddf4a6a..c37a17c32d74 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1051,7 +1051,7 @@ bool opens_in_grace(struct net *); * FIXME: should we create a separate "struct lock_request" to help distinguish * these two uses? * - * The varous i_flctx lists are ordered by: + * The various i_flctx lists are ordered by: * * 1) lock owner * 2) lock range start -- 2.26.2
Re: [PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files
On 3/12/21 1:13 AM, Viresh Kumar wrote: > On 12-03-21, 01:09, Frank Rowand wrote: >> I suggested having the .dtso files include the .dts file because that is a >> relatively >> small and easy change to test. What would probably make more sense is the >> rename >> the existing overlay .dts files to be .dtso files and then for each overlay >> .dtso >> file create a new .dts file that #includes the corresponding .dtso file. >> This is >> more work and churn, but easier to document that the .dts files are a hack >> that is >> needed so that the corresponding .dtb.S files will be generated. > > What about creating links instead then ? > I don't really like the idea of using links here. Maybe it is best to make the changes needed to allow the unittest overlays to be .dtso instead of .dts. Off the top of my head: scripts/Makefile.lib: The rule for %.dtb.S invokes cmd_dt_S_dtb, which puts the overlay data in section .dtb.init.rodata, with a label pointing to the beginning of the overlay __dtb_XXX_begin and a label pointing to the end of the overlay __dtb_XXX_end, for the overlay named XXX. I _think_ that you could simply add a corresponding rule for %.dtbo.S using a new command cmd_dt_S_dtbo (the same as cmd_dt_S_dtb, except use labels __dtbo_XXX_begin and __dtbo_XXX_end). drivers/of/unittest.o: would need to have the #define of OVERLAY_INFO() changed to reflect the changed label names (use __dtbo_##overlayname##begin and __dtb_##overlay_name##_end). drivers/of/unittest-data/Makefile: In obj-$(CONFIG_OF_OVERLAY) change the *.dtb.o names to *.dtbo.o I'm not sure how the DTC_FLAGS_... += -@ differentiates between .dts / .dtb and .dtso / .dtbo That is worth looking at. -Frank
[PATCH] KVM: clean up the unused argument
From: Haiwei Li
kvm_msr_ignored_check function never uses vcpu argument. Clean up the
function and invokers.
Signed-off-by: Haiwei Li
---
arch/x86/kvm/x86.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 012d5df..27e9ee8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -271,8 +271,7 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
* When called, it means the previous get/set msr reached an invalid msr.
* Return true if we want to ignore/silent this failed msr access.
*/
-static bool kvm_msr_ignored_check(struct kvm_vcpu *vcpu, u32 msr,
- u64 data, bool write)
+static bool kvm_msr_ignored_check(u32 msr, u64 data, bool write)
{
const char *op = write ? "wrmsr" : "rdmsr";
@@ -1447,7 +1446,7 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu,
unsigned index, u64 *data)
if (r == KVM_MSR_RET_INVALID) {
/* Unconditionally clear the output for simplicity */
*data = 0;
- if (kvm_msr_ignored_check(vcpu, index, 0, false))
+ if (kvm_msr_ignored_check(index, 0, false))
r = 0;
}
@@ -1613,7 +1612,7 @@ static int kvm_set_msr_ignored_check(struct kvm_vcpu
*vcpu,
int ret = __kvm_set_msr(vcpu, index, data, host_initiated);
if (ret == KVM_MSR_RET_INVALID)
- if (kvm_msr_ignored_check(vcpu, index, data, true))
+ if (kvm_msr_ignored_check(index, data, true))
ret = 0;
return ret;
@@ -1651,7 +1650,7 @@ static int kvm_get_msr_ignored_check(struct kvm_vcpu
*vcpu,
if (ret == KVM_MSR_RET_INVALID) {
/* Unconditionally clear *data for simplicity */
*data = 0;
- if (kvm_msr_ignored_check(vcpu, index, 0, false))
+ if (kvm_msr_ignored_check(index, 0, false))
ret = 0;
}
--
1.8.3.1
Re: [PATCH v5 2/2] arm64: dts: qcom: Add sound node for sc7180-trogdor-coachz
Hi Doug,
Thanks for your time and inputs!!!
On 3/13/2021 2:58 AM, Doug Anderson wrote:
Hi,
On Fri, Mar 12, 2021 at 8:07 AM Srinivasa Rao Mandadapu
wrote:
This is a trgodor variant, required to have sound node variable
for coachz specific platform.
Signed-off-by: Srinivasa Rao Mandadapu
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
index 4ad520f00485..7eaad739b6f9 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-coachz.dtsi
@@ -89,6 +89,16 @@ &sn65dsi86_out {
data-lanes = <0 1 2 3>;
};
+&sound {
+ compatible = "google,sc7180-coachz";
+ model = "sc7180-adau7002-max98357a";
+ audio-routing = "PDM_DAT", "DMIC";
+};
+
+&multimedia0_codec {
+ sound-dai = <&adau7002>;
+};
+
Much nicer! The last nit is that "multimedia0_codec" is now sorted
incorrectly. It starts with "m" so it shouldn't come after "s". Yes, I
know that this rule means that these two things are no longer next to
each other, but that's the rule we have right now.
If it's important for you for them to sort together, I suppose you
could change the label to "sound_multimedia0_codec" though that's a
bit of a mouthful. I'll leave it up to you whether to rename (and keep
the current ordering) or keep the name (and move the node).
-Doug
I feel it's good to keep them together by changing name as you suggested.
I will change accordingly and re post it.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH] ia64: include: asm: Minor typo fixes in the file pgtable.h
On 3/12/21 8:55 PM, Bhaskar Chowdhury wrote:
>
> s/migraton/migration/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> arch/ia64/include/asm/pgtable.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
> index 9b4efe89e62d..00a76ed7e018 100644
> --- a/arch/ia64/include/asm/pgtable.h
> +++ b/arch/ia64/include/asm/pgtable.h
> @@ -328,7 +328,7 @@ extern void __ia64_sync_icache_dcache(pte_t pteval);
> static inline void set_pte(pte_t *ptep, pte_t pteval)
> {
> /* page is present && page is user && page is executable
> - * && (page swapin or new page or page migraton
> + * && (page swapin or new page or page migration
>* || copy_on_write with page copying.)
>*/
> if (pte_present_exec_user(pteval) &&
> --
--
~Randy
[PATCH v2] ASoC: amd: add support for rt5682 codec in machine driver
Add support for RT5682 codec in machine driver.
Signed-off-by: Vijendar Mukunda
---
v1->v2 : updated kconfig, spdx license, removed unnecessary initialization and
updated comment
sound/soc/amd/Kconfig| 5 +-
sound/soc/amd/acp-da7219-max98357a.c | 380 +++
2 files changed, 343 insertions(+), 42 deletions(-)
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
index a6ce000..43f5d29 100644
--- a/sound/soc/amd/Kconfig
+++ b/sound/soc/amd/Kconfig
@@ -5,14 +5,15 @@ config SND_SOC_AMD_ACP
This option enables ACP DMA support on AMD platform.
config SND_SOC_AMD_CZ_DA7219MX98357_MACH
- tristate "AMD CZ support for DA7219 and MAX9835"
+ tristate "AMD CZ support for DA7219, RT5682 and MAX9835"
select SND_SOC_DA7219
+ select SND_SOC_RT5682_I2C
select SND_SOC_MAX98357A
select SND_SOC_ADAU7002
select REGULATOR
depends on SND_SOC_AMD_ACP && I2C && GPIOLIB
help
-This option enables machine driver for DA7219 and MAX9835.
+This option enables machine driver for DA7219, RT5682 and MAX9835.
config SND_SOC_AMD_CZ_RT5645_MACH
tristate "AMD CZ support for RT5645"
diff --git a/sound/soc/amd/acp-da7219-max98357a.c
b/sound/soc/amd/acp-da7219-max98357a.c
index 849288d..9b3520e 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -1,27 +1,8 @@
-/*
- * Machine driver for AMD ACP Audio engine using DA7219 & MAX98357 codec
- *
- * Copyright 2017 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- */
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Machine driver for AMD ACP Audio engine using DA7219, RT5682 & MAX98357
codec
+//
+//Copyright 2017-2021 Advanced Micro Devices, Inc.
#include
#include
@@ -41,14 +22,19 @@
#include "acp.h"
#include "../codecs/da7219.h"
#include "../codecs/da7219-aad.h"
+#include "../codecs/rt5682.h"
#define CZ_PLAT_CLK 4800
#define DUAL_CHANNEL 2
+#define RT5682_PLL_FREQ (48000 * 512)
static struct snd_soc_jack cz_jack;
static struct clk *da7219_dai_wclk;
static struct clk *da7219_dai_bclk;
-extern bool bt_uart_enable;
+static struct clk *rt5682_dai_wclk;
+static struct clk *rt5682_dai_bclk;
+extern int bt_uart_enable;
+void *soc_is_rltk_max(struct device *dev);
static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
{
@@ -128,6 +114,88 @@ static void da7219_clk_disable(void)
clk_disable_unprepare(da7219_dai_bclk);
}
+static int cz_rt5682_init(struct snd_soc_pcm_runtime *rtd)
+{
+ int ret;
+ struct snd_soc_card *card = rtd->card;
+ struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+ struct snd_soc_component *component = codec_dai->component;
+
+ dev_info(codec_dai->dev, "codec dai name = %s\n", codec_dai->name);
+
+ /* Set codec sysclk */
+ ret = snd_soc_dai_set_sysclk(codec_dai, RT5682_SCLK_S_PLL2,
+RT5682_PLL_FREQ, SND_SOC_CLOCK_IN);
+ if (ret < 0) {
+ dev_err(codec_dai->dev,
+ "Failed to set rt5682 SYSCLK: %d\n", ret);
+ return ret;
+ }
+ /* set codec PLL */
+ ret = snd_soc_dai_set_pll(codec_dai, RT5682_PLL2, RT5682_PLL2_S_MCLK,
+ CZ_PLAT_CLK, RT5682_PLL_FREQ);
+ if (ret < 0) {
+ dev_err(codec_dai->dev, "can't set rt5682 PLL: %d\n", ret);
+ return ret;
+ }
+
+ rt5682_dai_wclk = devm_clk_get(component->dev, "rt5682-dai-wclk");
+ if (IS_ERR(rt5682_dai_wclk))
+ return PTR_ERR(rt5682_dai_wclk);
+
+ rt5682_dai_bclk = devm_clk_get(component->dev, "rt5682-dai-bclk");
+ if (IS_ERR(rt5682_dai_bclk))
+ return PTR_ERR(rt5682_dai_bclk);
+
+ ret = snd_soc_card_jack_new(card, "Headset Jack",
+
[PATCH] ia64: include: asm: Minor typo fixes in the file pgtable.h
s/migraton/migration/
Signed-off-by: Bhaskar Chowdhury
---
arch/ia64/include/asm/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 9b4efe89e62d..00a76ed7e018 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -328,7 +328,7 @@ extern void __ia64_sync_icache_dcache(pte_t pteval);
static inline void set_pte(pte_t *ptep, pte_t pteval)
{
/* page is present && page is user && page is executable
-* && (page swapin or new page or page migraton
+* && (page swapin or new page or page migration
* || copy_on_write with page copying.)
*/
if (pte_present_exec_user(pteval) &&
--
2.26.2
Re: [PATCH V3] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c
On 3/12/21 7:49 PM, Bhaskar Chowdhury wrote: > > Trivial spelling fixes throughout the file. > > Signed-off-by: Bhaskar Chowdhury > --- > Changes from V2: > Incoporated the findings of Tom Saeger typo^^^ > > drivers/cpufreq/s5pv210-cpufreq.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c > b/drivers/cpufreq/s5pv210-cpufreq.c > index 69786e5bbf05..73110b005716 100644 > --- a/drivers/cpufreq/s5pv210-cpufreq.c > +++ b/drivers/cpufreq/s5pv210-cpufreq.c Reviewed-by: Randy Dunlap Thanks. -- ~Randy
Re: [PATCH v5 1/2] arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for I2S driver
Hi Doug,
Thanks for your time and inputs!!!
On 3/13/2021 2:58 AM, Doug Anderson wrote:
Hi,
On Fri, Mar 12, 2021 at 8:06 AM Srinivasa Rao Mandadapu
wrote:
+ dai-link@0 {
+ link-name = "MultiMedia0";
+ reg = ;
+ cpu {
+ sound-dai = <&lpass_cpu MI2S_PRIMARY>;
+ };
+
+ multimedia0_codec: codec {
+ sound-dai = <&alc5682 MI2S_PRIMARY>;
Please change "MI2S_PRIMARY" to "0". "MI2S_PRIMARY" is a numbering
system for "lpass_cpu" not for "alc5682". I'm not aware of symbolic
names for the alc5682's DAIs.
From digging through the code and testing, it appears that for alc5682:
0 - aif1
1 - aif2
Thus you could be a little more documenting by doing:
sound-dai = <&alc5682 0 /*aif1*/>;
-Doug
Okay, I will change accordingly.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH] drm/kmb: remove unneeded semicolon
From: Junlin Yang
Fixes coccicheck warnings:
./drivers/gpu/drm/kmb/kmb_dsi.c:284:3-4: Unneeded semicolon
./drivers/gpu/drm/kmb/kmb_dsi.c:304:3-4: Unneeded semicolon
./drivers/gpu/drm/kmb/kmb_dsi.c:321:3-4: Unneeded semicolon
./drivers/gpu/drm/kmb/kmb_dsi.c:340:3-4: Unneeded semicolon
./drivers/gpu/drm/kmb/kmb_dsi.c:364:2-3: Unneeded semicolon
Signed-off-by: Junlin Yang
---
drivers/gpu/drm/kmb/kmb_dsi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
index 4b5d82a..231041b 100644
--- a/drivers/gpu/drm/kmb/kmb_dsi.c
+++ b/drivers/gpu/drm/kmb/kmb_dsi.c
@@ -281,7 +281,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_PPS_YCBCR422_16B:
data_type_param.size_constraint_pixels = 2;
@@ -301,7 +301,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_LPPS_YCBCR422_20B:
case DSI_LP_DT_PPS_YCBCR422_24B:
@@ -318,7 +318,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_PPS_RGB565_16B:
data_type_param.size_constraint_pixels = 1;
@@ -337,7 +337,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_mode %d\n", data_mode);
return -EINVAL;
- };
+ }
break;
case DSI_LP_DT_PPS_RGB666_18B:
data_type_param.size_constraint_pixels = 4;
@@ -361,7 +361,7 @@ static u32 mipi_get_datatype_params(u32 data_type, u32
data_mode,
default:
DRM_ERROR("DSI: Invalid data_type %d\n", data_type);
return -EINVAL;
- };
+ }
*params = data_type_param;
return 0;
--
1.9.1
RE: [PATCH net-next] hv_netvsc: Add a comment clarifying batching logic
> From: LKML haiyangz On Behalf Of Haiyang Zhang > Sent: Friday, March 12, 2021 3:45 PM > To: linux-hyp...@vger.kernel.org; net...@vger.kernel.org > Cc: Haiyang Zhang ; KY Srinivasan > ; Stephen Hemminger ; > o...@aepfle.de; vkuznets ; da...@davemloft.net; > linux-kernel@vger.kernel.org; Shachar Raindel > Subject: [PATCH net-next] hv_netvsc: Add a comment clarifying batching logic > > From: Shachar Raindel > > The batching logic in netvsc_send is non-trivial, due to > a combination of the Linux API and the underlying hypervisor > interface. Add a comment explaining why the code is written this > way. > > Signed-off-by: Shachar Raindel > Signed-off-by: Haiyang Zhang > --- Reviewed-by: Dexuan Cui
Re: [PATCH v2 00/25] KVM SGX virtualization support
On Fri, 2021-03-12 at 14:04 -0800, Sean Christopherson wrote: > On Tue, Mar 09, 2021, Paolo Bonzini wrote: > > On 09/03/21 10:30, Borislav Petkov wrote: > > > On Tue, Mar 09, 2021 at 02:38:49PM +1300, Kai Huang wrote: > > > > This series adds KVM SGX virtualization support. The first 14 patches > > > > starting > > > > with x86/sgx or x86/cpu.. are necessary changes to x86 and SGX > > > > core/driver to > > > > support KVM SGX virtualization, while the rest are patches to KVM > > > > subsystem. > > > > > > Ok, I guess I'll queue 1-14 once Sean doesn't find anything > > > objectionable then give Paolo an immutable commit to base the KVM stuff > > > ontop. > > > > Sounds great. > > Patches 1-14 look good, just a few minor nits, nothing functional. I'll look > at > the KVM patches next week. > > Thanks for picking this up Kai! Thank you Sean! I'll address your comments in next version.
[PATCH] mm/oom_kill: fix wild pointer in out_of_memory
From: Bin Lai
From: Bin Lai
The oc->chosen is used by oom implementation, and the caller does
not initialize this variable. If the tasks of memcg are all unkillable,
oom_evaluate_task cann't choose any task, and the oc->chosen will be
a wild pointer. So we should initialize oc->chosen before calling
oom_evaluate_task.
Signed-off-by: Bin Lai
Reviewed-by: Jiang Biao
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 9efaf43..0658a30 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -366,6 +366,7 @@ static int oom_evaluate_task(struct task_struct *task, void
*arg)
static void select_bad_process(struct oom_control *oc)
{
oc->chosen_points = LONG_MIN;
+ oc->chosen = NULL;
if (is_memcg_oom(oc))
mem_cgroup_scan_tasks(oc->memcg, oom_evaluate_task, oc);
--
1.8.3.1
Re: [PATCH V3] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c
On Sat, Mar 13, 2021 at 09:19:51AM +0530, Bhaskar Chowdhury wrote:
>
> Trivial spelling fixes throughout the file.
>
LGTM
Reviewed-by: Tom Saeger
> Signed-off-by: Bhaskar Chowdhury
> ---
> Changes from V2:
> Incoporated the findings of Tom Saeger
>
> drivers/cpufreq/s5pv210-cpufreq.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
> b/drivers/cpufreq/s5pv210-cpufreq.c
> index 69786e5bbf05..73110b005716 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -91,7 +91,7 @@ static DEFINE_MUTEX(set_freq_lock);
> /* Use 800MHz when entering sleep mode */
> #define SLEEP_FREQ (800 * 1000)
>
> -/* Tracks if cpu freqency can be updated anymore */
> +/* Tracks if cpu frequency can be updated anymore */
> static bool no_cpufreq_access;
>
> /*
> @@ -190,7 +190,7 @@ static u32 clkdiv_val[5][11] = {
>
> /*
> * This function set DRAM refresh counter
> - * accoriding to operating frequency of DRAM
> + * according to operating frequency of DRAM
> * ch: DMC port number 0 or 1
> * freq: Operating frequency of DRAM(KHz)
> */
> @@ -320,7 +320,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
>
> /*
>* 3. DMC1 refresh count for 133Mhz if (index == L4) is
> - * true refresh counter is already programed in upper
> + * true refresh counter is already programmed in upper
>* code. 0x287@83Mhz
>*/
> if (!bus_speed_changing)
> @@ -378,7 +378,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
> /*
>* 6. Turn on APLL
>* 6-1. Set PMS values
> - * 6-2. Wait untile the PLL is locked
> + * 6-2. Wait until the PLL is locked
>*/
> if (index == L0)
> writel_relaxed(APLL_VAL_1000, S5P_APLL_CON);
> @@ -390,7 +390,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
> } while (!(reg & (0x1 << 29)));
>
> /*
> - * 7. Change souce clock from SCLKMPLL(667Mhz)
> + * 7. Change source clock from SCLKMPLL(667Mhz)
>* to SCLKA2M(200Mhz) in MFC_MUX and G3D MUX
>* (667/4=166)->(200/4=50)Mhz
>*/
> @@ -439,7 +439,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
> unsigned int index)
> }
>
> /*
> - * L4 level need to change memory bus speed, hence onedram clock divier
> + * L4 level needs to change memory bus speed, hence onedram clock
> divider
>* and memory refresh parameter should be changed
>*/
> if (bus_speed_changing) {
> --
> 2.26.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 3/7] tracing: Pass buffer of event to trigger operations
Hi Steven,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on linus/master v5.12-rc2 next-20210312]
[cannot apply to tip/perf/core hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Steven-Rostedt/tracing-Have-ring_buffer_event_time_stamp-work-for-all-events/20210313-051807
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
a74e6a014c9d4d4161061f770c9b4f98372ac778
config: x86_64-randconfig-a004-20210312 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
dfd27ebbd0eb137c9a439b7c537bb87ba903efd3)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/e0953acfef6e9234feed2877ed1b0a796755ceb6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Steven-Rostedt/tracing-Have-ring_buffer_event_time_stamp-work-for-all-events/20210313-051807
git checkout e0953acfef6e9234feed2877ed1b0a796755ceb6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> kernel/trace/trace_events_hist.c:3191:30: error: incompatible function
>> pointer types assigning to 'action_fn_t' (aka 'void (*)(struct
>> hist_trigger_data *, struct tracing_map_elt *, struct trace_buffer *, void
>> *, struct ring_buffer_event *, void *, struct action_data *, unsigned long
>> long *)') from 'void (struct hist_trigger_data *, struct tracing_map_elt *,
>> void *, struct ring_buffer_event *, void *, struct action_data *, u64 *)'
>> (aka 'void (struct hist_trigger_data *, struct tracing_map_elt *, void *,
>> struct ring_buffer_event *, void *, struct action_data *, unsigned long long
>> *)') [-Werror,-Wincompatible-function-pointer-types]
data->track_data.save_data = save_track_data_snapshot;
^
1 error generated.
vim +3191 kernel/trace/trace_events_hist.c
50450603ec9cb8 Tom Zanussi 2018-01-15 3125
d0cd871ba0d613 Steven Rostedt (VMware 2019-04-01 3126) static int
action_parse(struct trace_array *tr, char *str, struct action_data *data,
7d18a10c316783 Tom Zanussi 2019-02-13 3127
enum handler_id handler)
7d18a10c316783 Tom Zanussi 2019-02-13 3128 {
7d18a10c316783 Tom Zanussi 2019-02-13 3129 char
*action_name;
7d18a10c316783 Tom Zanussi 2019-02-13 3130 int ret = 0;
7d18a10c316783 Tom Zanussi 2019-02-13 3131
7d18a10c316783 Tom Zanussi 2019-02-13 3132 strsep(&str,
".");
7d18a10c316783 Tom Zanussi 2019-02-13 3133 if (!str) {
d0cd871ba0d613 Steven Rostedt (VMware 2019-04-01 3134)
hist_err(tr, HIST_ERR_ACTION_NOT_FOUND, 0);
7d18a10c316783 Tom Zanussi 2019-02-13 3135 ret =
-EINVAL;
7d18a10c316783 Tom Zanussi 2019-02-13 3136 goto
out;
7d18a10c316783 Tom Zanussi 2019-02-13 3137 }
7d18a10c316783 Tom Zanussi 2019-02-13 3138
7d18a10c316783 Tom Zanussi 2019-02-13 3139 action_name =
strsep(&str, "(");
7d18a10c316783 Tom Zanussi 2019-02-13 3140 if
(!action_name || !str) {
d0cd871ba0d613 Steven Rostedt (VMware 2019-04-01 3141)
hist_err(tr, HIST_ERR_ACTION_NOT_FOUND, 0);
7d18a10c316783 Tom Zanussi 2019-02-13 3142 ret =
-EINVAL;
7d18a10c316783 Tom Zanussi 2019-02-13 3143 goto
out;
7d18a10c316783 Tom Zanussi 2019-02-13 3144 }
7d18a10c316783 Tom Zanussi 2019-02-13 3145
7d18a10c316783 Tom Zanussi 2019-02-13 3146 if
(str_has_prefix(action_name, "save")) {
7d18a10c316783 Tom Zanussi 2019-02-13 3147 char
*params = strsep(&str, ")");
7d18a10c316783 Tom Zanussi 2019-02-13 3148
7d18a10c316783 Tom Zanussi 2019-02-13 3149 if
(!params) {
d0cd871ba0d613 Steven Rostedt (VMware 2019-04-01 3
Re: [PATCH] MAINTAINERS: update audit files
On 2021-03-12 16:38, Paul Moore wrote: > On Thu, Mar 11, 2021 at 11:41 AM Richard Guy Briggs wrote: > > Add files maintaned by the audit subsystem. > > > > Signed-off-by: Richard Guy Briggs > > --- > > MAINTAINERS | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 6eff4f720c72..a17532559665 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3015,9 +3015,13 @@ L: linux-au...@redhat.com (moderated for > > non-subscribers) > > S: Supported > > W: https://github.com/linux-audit > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git > > +F: arch/*/*/*audit*.[ch] > > That looks like it has about two too many wildcards to hold up over time :) > > I understand what you're trying to do here, and while I don't disagree > in principle, I worry that the arch specific paths vary enough that > trying to handle it here is going to be a bit of a mess. > > > +F: arch/x86/include/asm/audit.h > > The fact that we need a special entry for the single header under x86 > tends to reinforce that. The other additions make sense, but I think > it may be best to leave the arch specific areas alone for now. Ok, I should have labelled this "RFC". :-) > > +F: include/asm-generic/audit_*.h > > F: include/linux/audit.h > > F: include/uapi/linux/audit.h > > F: kernel/audit* > > +F: lib/*audit.c > > > > AUXILIARY DISPLAY DRIVERS > > M: Miguel Ojeda Sandonis > > -- > > 2.27.0 > > paul moore - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
RE: slow boot with 7fef431be9c9 ("mm/page_alloc: place pages to tail in __free_pages_core()")
[AMD Public Use]
Hi David,
Which benchmark tool you prefer? Memtest86+ or else?
BRs,
Leo
-Original Message-
From: David Hildenbrand
Sent: Saturday, March 13, 2021 12:47 AM
To: Liang, Liang (Leo) ; Deucher, Alexander
; linux-kernel@vger.kernel.org; amd-gfx list
; Andrew Morton
Cc: Huang, Ray ; Koenig, Christian
; Mike Rapoport ; Rafael J.
Wysocki ; George Kennedy
Subject: Re: slow boot with 7fef431be9c9 ("mm/page_alloc: place pages to tail
in __free_pages_core()")
On 12.03.21 17:19, Liang, Liang (Leo) wrote:
> [AMD Public Use]
>
> Dmesg attached.
>
So, looks like the "real" slowdown starts once the buddy is up and running (no
surprise).
[0.044035] Memory: 6856724K/7200304K available (14345K kernel code, 9699K
rwdata, 5276K rodata, 2628K init, 12104K bss, 343324K reserved, 0K cma-reserved)
[0.044045] random: get_random_u64 called from
__kmem_cache_create+0x33/0x460 with crng_init=1
[0.049025] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
[0.050036] ftrace: allocating 47158 entries in 185 pages
[0.097487] ftrace: allocated 185 pages with 5 groups
[0.109210] rcu: Hierarchical RCU implementation.
vs.
[0.041115] Memory: 6869396K/7200304K available (14345K kernel code, 3433K
rwdata, 5284K rodata, 2624K init, 6088K bss, 330652K reserved, 0K cma-reserved)
[0.041127] random: get_random_u64 called from
__kmem_cache_create+0x31/0x430 with crng_init=1
[0.041309] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
[0.041335] ftrace: allocating 47184 entries in 185 pages
[0.055719] ftrace: allocated 185 pages with 5 groups
[0.055863] rcu: Hierarchical RCU implementation.
And it gets especially bad during ACPI table processing:
[4.158303] ACPI: Added _OSI(Module Device)
[4.158767] ACPI: Added _OSI(Processor Device)
[4.159230] ACPI: Added _OSI(3.0 _SCP Extensions)
[4.159705] ACPI: Added _OSI(Processor Aggregator Device)
[4.160551] ACPI: Added _OSI(Linux-Dell-Video)
[4.161359] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[4.162264] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 17.713421] ACPI: 13 ACPI AML tables successfully acquired and loaded
[ 18.716065] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 20.743828] ACPI: EC: EC started
[ 20.744155] ACPI: EC: interrupt blocked
[ 20.945956] ACPI: EC: EC_CMD/EC_SC=0x666, EC_DATA=0x662
[ 20.946618] ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC used to handle
transactions
[ 20.947348] ACPI: Interpreter enabled
[ 20.951278] ACPI: (supports S0 S3 S4 S5)
[ 20.951632] ACPI: Using IOAPIC for interrupt routing
vs.
[0.216039] ACPI: Added _OSI(Module Device)
[0.216041] ACPI: Added _OSI(Processor Device)
[0.216043] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.216044] ACPI: Added _OSI(Processor Aggregator Device)
[0.216046] ACPI: Added _OSI(Linux-Dell-Video)
[0.216048] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[0.216049] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[0.228259] ACPI: 13 ACPI AML tables successfully acquired and loaded
[0.229527] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[0.231663] ACPI: EC: EC started
[0.231666] ACPI: EC: interrupt blocked
[0.233664] ACPI: EC: EC_CMD/EC_SC=0x666, EC_DATA=0x662
[0.233667] ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC used to handle
transactions
[0.233670] ACPI: Interpreter enabled
[0.233685] ACPI: (supports S0 S3 S4 S5)
[0.233687] ACPI: Using IOAPIC for interrupt routing
The jump from 4.1 -> 17.7 is especially bad.
Which might in fact indicate that this could be related to using some very
special slow (ACPI?) memory for ordinary purposes, interfering with actual ACPI
users?
But again, just a wild guess, because the system is extremely slow afterwards,
however, we don't have any pauses without any signs of life for that long.
It would be interesting to run a simple memory bandwidth benchmark on the fast
kernel with differing sizes up to running OOM to see if there is really some
memory that is just horribly slow once allocated and used.
--
Thanks,
David / dhildenb
Re: [PATCH V2] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c
On 19:59 Fri 12 Mar 2021, Tom Saeger wrote:
On Fri, Mar 12, 2021 at 04:57:07PM -0800, Randy Dunlap wrote:
On 3/12/21 4:50 PM, Bhaskar Chowdhury wrote:
> On 17:16 Fri 12 Mar 2021, Tom Saeger wrote:
>> On Sat, Mar 13, 2021 at 04:56:21AM +0530, Bhaskar Chowdhury wrote:
>>
>> sent a few additional typo fixes to your V1, can you add those to your patch?
>>
>> Regards,
>>
>> --Tom
>
> Thanks, I have already sent out a V2 in public...I might make a V3 with your
> changes too...did you sent it to ???
It was just a reply to your v1 patch.
--
~Randy
Bhaskar,
Here you go...
V2 additions:
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index af1ac3f6e4b8..73110b005716 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -91,7 +91,7 @@ static DEFINE_MUTEX(set_freq_lock);
/* Use 800MHz when entering sleep mode */
#define SLEEP_FREQ (800 * 1000)
-/* Tracks if cpu freqency can be updated anymore */
+/* Tracks if cpu frequency can be updated anymore */
static bool no_cpufreq_access;
/*
@@ -190,7 +190,7 @@ static u32 clkdiv_val[5][11] = {
/*
* This function set DRAM refresh counter
- * accoriding to operating frequency of DRAM
+ * according to operating frequency of DRAM
* ch: DMC port number 0 or 1
* freq: Operating frequency of DRAM(KHz)
*/
@@ -320,7 +320,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
/*
* 3. DMC1 refresh count for 133Mhz if (index == L4) is
-* true refresh counter is already programed in upper
+* true refresh counter is already programmed in upper
* code. 0x287@83Mhz
*/
if (!bus_speed_changing)
Tom,
I sent out an V3 incorporated with your findings.
Thanks,
Bhaskar
signature.asc
Description: PGP signature
[PATCH V3] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c
Trivial spelling fixes throughout the file.
Signed-off-by: Bhaskar Chowdhury
---
Changes from V2:
Incoporated the findings of Tom Saeger
drivers/cpufreq/s5pv210-cpufreq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index 69786e5bbf05..73110b005716 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -91,7 +91,7 @@ static DEFINE_MUTEX(set_freq_lock);
/* Use 800MHz when entering sleep mode */
#define SLEEP_FREQ (800 * 1000)
-/* Tracks if cpu freqency can be updated anymore */
+/* Tracks if cpu frequency can be updated anymore */
static bool no_cpufreq_access;
/*
@@ -190,7 +190,7 @@ static u32 clkdiv_val[5][11] = {
/*
* This function set DRAM refresh counter
- * accoriding to operating frequency of DRAM
+ * according to operating frequency of DRAM
* ch: DMC port number 0 or 1
* freq: Operating frequency of DRAM(KHz)
*/
@@ -320,7 +320,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
/*
* 3. DMC1 refresh count for 133Mhz if (index == L4) is
-* true refresh counter is already programed in upper
+* true refresh counter is already programmed in upper
* code. 0x287@83Mhz
*/
if (!bus_speed_changing)
@@ -378,7 +378,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
/*
* 6. Turn on APLL
* 6-1. Set PMS values
-* 6-2. Wait untile the PLL is locked
+* 6-2. Wait until the PLL is locked
*/
if (index == L0)
writel_relaxed(APLL_VAL_1000, S5P_APLL_CON);
@@ -390,7 +390,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
} while (!(reg & (0x1 << 29)));
/*
-* 7. Change souce clock from SCLKMPLL(667Mhz)
+* 7. Change source clock from SCLKMPLL(667Mhz)
* to SCLKA2M(200Mhz) in MFC_MUX and G3D MUX
* (667/4=166)->(200/4=50)Mhz
*/
@@ -439,7 +439,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
}
/*
-* L4 level need to change memory bus speed, hence onedram clock divier
+* L4 level needs to change memory bus speed, hence onedram clock
divider
* and memory refresh parameter should be changed
*/
if (bus_speed_changing) {
--
2.26.2
[PATCH] clk: clk.c: Fixed statics initialized to 0
Uninitialized static variable from 0, as statics get auto-initialized to 0 during execution. Signed-off-by: Pallavi Prabhu --- drivers/clk/clk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 5052541a0986..763ad2c960bd 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -2931,7 +2931,7 @@ EXPORT_SYMBOL_GPL(clk_is_match); #include static struct dentry *rootdir; -static int inited = 0; +static int inited; static DEFINE_MUTEX(clk_debug_lock); static HLIST_HEAD(clk_debug_list); -- 2.25.1
Re: [PATCH] fs: overlayfs: Trivial typo fixes in the file inode.c
On 3/12/21 7:30 PM, Bhaskar Chowdhury wrote:
>
> s/peresistent/persistent/
> s/xatts/xattrs/ ---> this is a filesystem attribute, so, it spell like this.
> s/annotaion/annotation/
>
>
> Signed-off-by: Bhaskar Chowdhury
In the future, please drop "fs: " in the Subject:. Compare:
$ git log --oneline fs/overlayfs/
d46b7cd68336 ovl: plumb through flush method
335d3fc57941 ovl: implement volatile-specific fsync error behaviour
03fedf93593c ovl: skip getxattr of security labels
e04527fefba6 ovl: fix dentry leak in ovl_get_redirect
b854cc659dcb ovl: avoid deadlock on directory ioctl
554677b97257 ovl: perform vfs_getxattr() with mounter creds
9efb069de4ba ovl: add warning on user_ns mismatch
029a52ada6a7 overlayfs: do not mount on top of idmapped mounts
549c7297717c fs: make helpers idmap mount aware
6521f8917082 namei: prepare for idmapped mounts
9fe61450972d namei: introduce struct renamedata
c7c7a1a18af4 xattr: handle idmapped mounts
e65ce2a50cf6 acl: handle idmapped mounts
2f221d6f7b88 attr: handle idmapped mounts
21cb47be6fb9 inode: make init and permission helpers idmapped mount aware
47291baa8ddf namei: make permission helpers idmapped mount aware
0558c1bf5a08 capability: handle idmapped mounts
459c7c565ac3 ovl: unprivieged mounts
87b2c60c6127 ovl: do not get metacopy for userxattr
b6650dab404c ovl: do not fail because of O_NOATIME
6939f977c54a ovl: do not fail when setting origin xattr
2d2f2d7322ff ovl: user xattr
82a763e61e2b ovl: simplify file splice
89bdfaf93d91 ovl: make ioctl() safe
c846af050f94 ovl: check privs before decoding file handle
> ---
> Note: The second change has nothing to do with dictionary words.
>
> fs/overlayfs/inode.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
> index d739e14c6814..e5588fc90a7d 100644
> --- a/fs/overlayfs/inode.c
> +++ b/fs/overlayfs/inode.c
> @@ -114,7 +114,7 @@ static int ovl_map_dev_ino(struct dentry *dentry, struct
> kstat *stat, int fsid)
>* high xinobits, so we use high xinobits to partition the
>* overlay st_ino address space. The high bits holds the fsid
>* (upper fsid is 0). The lowest xinobit is reserved for mapping
> - * the non-peresistent inode numbers range in case of overflow.
> + * the non-persistent inode numbers range in case of overflow.
>* This way all overlay inode numbers are unique and use the
>* overlay st_dev.
>*/
> @@ -403,7 +403,7 @@ static bool ovl_can_list(struct super_block *sb, const
> char *s)
> if (ovl_is_private_xattr(sb, s))
> return false;
>
> - /* List all non-trusted xatts */
> + /* List all non-trusted xattrs */
> if (strncmp(s, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN) != 0)
> return true;
>
> @@ -533,7 +533,7 @@ static const struct address_space_operations ovl_aops = {
> * stackable i_mutex locks according to stack level of the super
> * block instance. An overlayfs instance can never be in stack
> * depth 0 (there is always a real fs below it). An overlayfs
> - * inode lock will use the lockdep annotaion ovl_i_mutex_key[depth].
> + * inode lock will use the lockdep annotation ovl_i_mutex_key[depth].
> *
> * For example, here is a snip from /proc/lockdep_chains after
> * dir_iterate of nested overlayfs:
> --
Acked-by: Randy Dunlap
--
~Randy
Re: [PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
On 3/12/21 7:32 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
When hotplug and DPC are both enabled on a Root port or
Downstream Port, during DPC events that cause a DLLSC link
down/up events, such events (DLLSC) must be suppressed to
let the DPC driver own the recovery path.
When DPC is present and enabled, hardware will put the port in
containment state to allow SW to recover from the error condition
in the seamless manner. But, during the DPC error recovery process,
since the link is in disabled state, it will also raise the DLLSC
event. In Linux kernel architecture, DPC events are handled by DPC
driver and DLLSC events are handled by hotplug driver. If a hotplug
driver is allowed to handle such DLLSC event (triggered by DPC
containment), then we will have a race condition between error
recovery handler (in DPC driver) and hotplug handler in recovering
the contained port. Allowing such a race leads to a lot of stability
issues while recovering the device. So skip DLLSC handling in the
hotplug driver when the PCIe port associated with the hotplug event is
in DPC triggered state and let the DPC driver be responsible for the
port recovery.
Following is the sample dmesg log which shows the contention
between hotplug handler and error recovery handler. In this
case, hotplug handler won the race and error recovery
handler reported failure.
pcieport :97:02.0: pciehp: Slot(4): Link Down
pcieport :97:02.0: DPC: containment event, status:0x1f01 source:0x
pcieport :97:02.0: DPC: unmasked uncorrectable error detected
pcieport :97:02.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal),
type=Transaction Layer, (Requester ID)
pcieport :97:02.0: device [8086:347a] error status/mask=4000/00100020
pcieport :97:02.0:[14] CmpltTO(First)
pci :98:00.0: AER: can't recover (no error_detected callback)
pcieport :97:02.0: pciehp: Slot(4): Card present
pcieport :97:02.0: DPC: Data Link Layer Link Active not set in 1000 msec
pcieport :97:02.0: AER: subordinate device reset failed
pcieport :97:02.0: AER: device recovery failed
pci :98:00.0: [8086:0953] type 00 class 0x010802
nvme nvme1: pci function :98:00.0
nvme :98:00.0: enabling device (0140 -> 0142)
nvme nvme1: 31/0/0 default/read/poll queues
nvme1n2: p1
Signed-off-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Dan Williams
Reviewed-by: Raj Ashok
---
Missed to add the change log. will include it in next version.
Changes since v1:
* Trimmed down the kernel log in commit history.
* Removed usage of !! in is_dpc_reset_active().
* Addressed other minor comments from Bjorn.
drivers/pci/hotplug/pciehp_hpc.c | 19 +
drivers/pci/pci.h| 2 ++
drivers/pci/pcie/dpc.c | 36 ++--
include/linux/pci.h | 1 +
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index fb3840e222ad..55da5208c7e5 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -691,6 +691,25 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
goto out;
}
+ /*
+* If the DLLSC link up/down event is generated due to DPC containment
+* in the PCIe port, skip the DLLSC event handling and let the DPC
+* driver own the port recovery. Allowing both hotplug DLLSC event
+* handler and DPC event trigger handler to attempt recovery on the
+* same port leads to stability issues. If DPC recovery is successful,
+* is_dpc_reset_active() will return false and the hotplug handler will
+* not suppress the DLLSC event. If DPC recovery fails and the link is
+* left in disabled state, once the user changes the faulty card, the
+* hotplug handler can still handle the PRESENCE change event and bring
+* the device back up.
+*/
+ if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
+ ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
+ slot_name(ctrl));
+ ret = IRQ_HANDLED;
+ goto out;
+ }
+
/* Check Attention Button Pressed */
if (events & PCI_EXP_SLTSTA_ABP) {
ctrl_info(ctrl, "Slot(%s): Attention button pressed\n",
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index ef7c4661314f..cee7095483bd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -446,10 +446,12 @@ void pci_restore_dpc_state(struct pci_dev *dev);
void pci_dpc_init(struct pci_dev *pdev);
void dpc_process_error(struct pci_dev *pdev);
pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
+bool is_dpc_reset_active(struct pci_dev *pdev);
#else
static inline void pci_save_dpc_state(struct pci_dev *dev) {}
static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
[PATCH] mips: kernel: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
debugfs_create_file_unsafe does not protect the fops handed to it
against file removal. DEFINE_DEBUGFS_ATTRIBUTE makes the fops aware of
the file lifetime and thus protects it against removal.
Signed-off-by: Wang Qing
---
arch/mips/kernel/spinlock_test.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/kernel/spinlock_test.c b/arch/mips/kernel/spinlock_test.c
index ab4e3e1..90f53e0
--- a/arch/mips/kernel/spinlock_test.c
+++ b/arch/mips/kernel/spinlock_test.c
@@ -35,7 +35,7 @@ static int ss_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(fops_ss, ss_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_ss, ss_get, NULL, "%llu\n");
@@ -114,13 +114,13 @@ static int multi_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(fops_multi, multi_get, NULL, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(fops_multi, multi_get, NULL, "%llu\n");
static int __init spinlock_test(void)
{
- debugfs_create_file("spin_single", S_IRUGO, mips_debugfs_dir, NULL,
+ debugfs_create_file_unsafe("spin_single", S_IRUGO, mips_debugfs_dir,
NULL,
&fops_ss);
- debugfs_create_file("spin_multi", S_IRUGO, mips_debugfs_dir, NULL,
+ debugfs_create_file_unsafe("spin_multi", S_IRUGO, mips_debugfs_dir,
NULL,
&fops_multi);
return 0;
}
--
2.7.4
[PATCH] soc: ti: Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
Fix the following coccicheck warning: WARNING:pm_sr_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE. Signed-off-by: Wang Qing --- drivers/soc/ti/smartreflex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/ti/smartreflex.c b/drivers/soc/ti/smartreflex.c index 5376f3d..b3c7460 --- a/drivers/soc/ti/smartreflex.c +++ b/drivers/soc/ti/smartreflex.c @@ -817,7 +817,7 @@ static int omap_sr_autocomp_store(void *data, u64 val) return 0; } -DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show, +DEFINE_DEBUGFS_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show, omap_sr_autocomp_store, "%llu\n"); static int omap_sr_probe(struct platform_device *pdev) -- 2.7.4
[PATCH] fs: overlayfs: Trivial typo fixes in the file inode.c
s/peresistent/persistent/
s/xatts/xattrs/ ---> this is a filesystem attribute, so, it spell like this.
s/annotaion/annotation/
Signed-off-by: Bhaskar Chowdhury
---
Note: The second change has nothing to do with dictionary words.
fs/overlayfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index d739e14c6814..e5588fc90a7d 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -114,7 +114,7 @@ static int ovl_map_dev_ino(struct dentry *dentry, struct
kstat *stat, int fsid)
* high xinobits, so we use high xinobits to partition the
* overlay st_ino address space. The high bits holds the fsid
* (upper fsid is 0). The lowest xinobit is reserved for mapping
-* the non-peresistent inode numbers range in case of overflow.
+* the non-persistent inode numbers range in case of overflow.
* This way all overlay inode numbers are unique and use the
* overlay st_dev.
*/
@@ -403,7 +403,7 @@ static bool ovl_can_list(struct super_block *sb, const char
*s)
if (ovl_is_private_xattr(sb, s))
return false;
- /* List all non-trusted xatts */
+ /* List all non-trusted xattrs */
if (strncmp(s, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN) != 0)
return true;
@@ -533,7 +533,7 @@ static const struct address_space_operations ovl_aops = {
* stackable i_mutex locks according to stack level of the super
* block instance. An overlayfs instance can never be in stack
* depth 0 (there is always a real fs below it). An overlayfs
- * inode lock will use the lockdep annotaion ovl_i_mutex_key[depth].
+ * inode lock will use the lockdep annotation ovl_i_mutex_key[depth].
*
* For example, here is a snip from /proc/lockdep_chains after
* dir_iterate of nested overlayfs:
--
2.26.2
[PATCH v2 1/1] PCI: pciehp: Skip DLLSC handling if DPC is triggered
From: Kuppuswamy Sathyanarayanan
When hotplug and DPC are both enabled on a Root port or
Downstream Port, during DPC events that cause a DLLSC link
down/up events, such events (DLLSC) must be suppressed to
let the DPC driver own the recovery path.
When DPC is present and enabled, hardware will put the port in
containment state to allow SW to recover from the error condition
in the seamless manner. But, during the DPC error recovery process,
since the link is in disabled state, it will also raise the DLLSC
event. In Linux kernel architecture, DPC events are handled by DPC
driver and DLLSC events are handled by hotplug driver. If a hotplug
driver is allowed to handle such DLLSC event (triggered by DPC
containment), then we will have a race condition between error
recovery handler (in DPC driver) and hotplug handler in recovering
the contained port. Allowing such a race leads to a lot of stability
issues while recovering the device. So skip DLLSC handling in the
hotplug driver when the PCIe port associated with the hotplug event is
in DPC triggered state and let the DPC driver be responsible for the
port recovery.
Following is the sample dmesg log which shows the contention
between hotplug handler and error recovery handler. In this
case, hotplug handler won the race and error recovery
handler reported failure.
pcieport :97:02.0: pciehp: Slot(4): Link Down
pcieport :97:02.0: DPC: containment event, status:0x1f01 source:0x
pcieport :97:02.0: DPC: unmasked uncorrectable error detected
pcieport :97:02.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal),
type=Transaction Layer, (Requester ID)
pcieport :97:02.0: device [8086:347a] error status/mask=4000/00100020
pcieport :97:02.0:[14] CmpltTO(First)
pci :98:00.0: AER: can't recover (no error_detected callback)
pcieport :97:02.0: pciehp: Slot(4): Card present
pcieport :97:02.0: DPC: Data Link Layer Link Active not set in 1000 msec
pcieport :97:02.0: AER: subordinate device reset failed
pcieport :97:02.0: AER: device recovery failed
pci :98:00.0: [8086:0953] type 00 class 0x010802
nvme nvme1: pci function :98:00.0
nvme :98:00.0: enabling device (0140 -> 0142)
nvme nvme1: 31/0/0 default/read/poll queues
nvme1n2: p1
Signed-off-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Dan Williams
Reviewed-by: Raj Ashok
---
drivers/pci/hotplug/pciehp_hpc.c | 19 +
drivers/pci/pci.h| 2 ++
drivers/pci/pcie/dpc.c | 36 ++--
include/linux/pci.h | 1 +
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index fb3840e222ad..55da5208c7e5 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -691,6 +691,25 @@ static irqreturn_t pciehp_ist(int irq, void *dev_id)
goto out;
}
+ /*
+* If the DLLSC link up/down event is generated due to DPC containment
+* in the PCIe port, skip the DLLSC event handling and let the DPC
+* driver own the port recovery. Allowing both hotplug DLLSC event
+* handler and DPC event trigger handler to attempt recovery on the
+* same port leads to stability issues. If DPC recovery is successful,
+* is_dpc_reset_active() will return false and the hotplug handler will
+* not suppress the DLLSC event. If DPC recovery fails and the link is
+* left in disabled state, once the user changes the faulty card, the
+* hotplug handler can still handle the PRESENCE change event and bring
+* the device back up.
+*/
+ if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
+ ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC), skipped\n",
+ slot_name(ctrl));
+ ret = IRQ_HANDLED;
+ goto out;
+ }
+
/* Check Attention Button Pressed */
if (events & PCI_EXP_SLTSTA_ABP) {
ctrl_info(ctrl, "Slot(%s): Attention button pressed\n",
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index ef7c4661314f..cee7095483bd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -446,10 +446,12 @@ void pci_restore_dpc_state(struct pci_dev *dev);
void pci_dpc_init(struct pci_dev *pdev);
void dpc_process_error(struct pci_dev *pdev);
pci_ers_result_t dpc_reset_link(struct pci_dev *pdev);
+bool is_dpc_reset_active(struct pci_dev *pdev);
#else
static inline void pci_save_dpc_state(struct pci_dev *dev) {}
static inline void pci_restore_dpc_state(struct pci_dev *dev) {}
static inline void pci_dpc_init(struct pci_dev *pdev) {}
+static inline bool is_dpc_reset_active(struct pci_dev *pdev) { return false; }
#endif
#ifdef CONFIG_PCIEPORTBUS
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c
index e05aba86a317..9157d70ebe21 100644
--- a/drivers/pci/pcie/dpc.c
+++ b/driv
[PATCH v3 2/2] rockchip: rk3399: Add support for FriendlyARM NanoPi R4S
This adds support for the NanoPi R4S from FriendlyArm.
Rockchip RK3399 SoC
1GB DDR3 or 4GB LPDDR4 RAM
Gigabit Ethernet (WAN)
Gigabit Ethernet (PCIe) (LAN)
USB 3.0 Port x 2
MicroSD slot
Reset button
WAN - LAN - SYS LED
[initial DTS file]
Co-developed-by: Jensen Huang
Signed-off-by: Jensen Huang
[minor adjustments]
Co-developed-by: Marty Jones
Signed-off-by: Marty Jones
[fixed format issues]
Signed-off-by: Tianling Shen
Reported-by: kernel test robot
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-r4s.dts | 179 ++
2 files changed, 180 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 62d3abc17a24..c3e00c0e2db7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -36,6 +36,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-r4s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
new file mode 100644
index ..41b3d5c5043c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dts
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPC-T4 board device tree source
+ *
+ * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ *
+ * Copyright (c) 2020 Jensen Huang
+ * Copyright (c) 2020 Marty Jones
+ * Copyright (c) 2021 Tianling Shen
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+ /delete-node/ gpio-leds;
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&lan_led_pin>, <&sys_led_pin>, <&wan_led_pin>;
+ pinctrl-names = "default";
+
+ lan_led: led-0 {
+ gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ sys_led: led-1 {
+ gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:red:sys";
+ default-state = "on";
+ };
+
+ wan_led: led-2 {
+ gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+ };
+
+ /delete-node/ gpio-keys;
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&reset_button_pin>;
+
+ reset {
+ debounce-interval = <50>;
+ gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+ label = "reset";
+ linux,code = ;
+ };
+ };
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ /*
+* With 20KHz PWM and an EVERCOOL EC4007H12SA fan, these levels
+* work out to 0, ~1200, ~3000, and 5000RPM respectively.
+*/
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vdd_5v>;
+ pwms = <&pwm1 0 5 0>;
+ };
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&emmc_phy {
+ status = "disabled";
+};
+
+&fusb0 {
+ status = "disabled";
+};
+
+&pcie0 {
+ max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <&vcc
[PATCH v3 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S
Add devicetree binding documentation for the FriendlyARM NanoPi R4S. Changes in v2: - Disable display for NanoPi R4S (reference commit: 74532de460ec) - Light "sys" LED on NanoPi R4S (reference commit: 833821eeab91) Changes in v3: - Dropped non-existent node `display_subsystem` Signed-off-by: Tianling Shen --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index c3036f95c7bc..4a6f772c1043 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -134,6 +134,7 @@ properties: - friendlyarm,nanopi-m4 - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 + - friendlyarm,nanopi-r4s - const: rockchip,rk3399 - description: GeekBuying GeekBox -- 2.17.1
Re: [PATCH] ACPI: fix various typos in comments
On 3/12/21 5:55 PM, Tom Saeger wrote: > Fix trivial ACPI driver comment typos. > > s/notifcations/notifications/ > s/Ajust/Adjust/ > s/preform/perform/ > s/atrributes/attributes/ > s/Souce/Source/ > s/Evalutes/Evaluates/ > s/Evalutes/Evaluates/ > s/specifiy/specify/ > s/promixity/proximity/ > s/presuambly/presumably/ > s/Evalute/Evaluate/ > s/specificed/specified/ > s/rountine/routine/ > s/previosuly/previously/ > > Change comment referencing pcc_send_cmd to send_pcc_cmd. > > Cc: triv...@kernel.org > Signed-off-by: Tom Saeger > --- > drivers/acpi/ac.c | 2 +- > drivers/acpi/acpi_video.c | 4 ++-- > drivers/acpi/apei/erst.c | 2 +- > drivers/acpi/apei/hest.c | 2 +- > drivers/acpi/cppc_acpi.c | 10 +- > drivers/acpi/numa/hmat.c | 2 +- > drivers/acpi/pmic/intel_pmic_chtcrc.c | 2 +- > drivers/acpi/power.c | 2 +- > drivers/acpi/processor_perflib.c | 2 +- > drivers/acpi/resource.c | 2 +- > drivers/acpi/scan.c | 2 +- > 11 files changed, 16 insertions(+), 16 deletions(-) Reviewed-by: Randy Dunlap Thanks. -- ~Randy
Re: [PATCH] mailbox: fix various typos in comments
On 3/12/21 6:31 PM, Tom Saeger wrote: > > Fix trivial typos in mailbox driver comments. > > s/Intergrated/Integrated/ > s/extenstion/extension/ > s/atleast/at least/ > s/commnunication/communication/ > s/assgined/assigned/ > s/commnunication/communication/ > s/recevied/received/ > s/succeded/succeeded/ > s/implmentation/implementation/ > s/definiation/definition/ > s/traget/target/ > s/wont/won't/ > > Cc: triv...@kernel.org > Signed-off-by: Tom Saeger Reviewed-by: Randy Dunlap Thanks. > --- > drivers/mailbox/Kconfig | 2 +- > drivers/mailbox/bcm-flexrm-mailbox.c| 4 ++-- > drivers/mailbox/mailbox-xgene-slimpro.c | 6 +++--- > drivers/mailbox/mailbox.h | 2 +- > drivers/mailbox/pcc.c | 2 +- > drivers/mailbox/pl320-ipc.c | 2 +- > drivers/mailbox/sprd-mailbox.c | 12 ++-- > drivers/mailbox/ti-msgmgr.c | 2 +- > 8 files changed, 16 insertions(+), 16 deletions(-) -- ~Randy
Re: [PATCH v2] hugetlb_cgroup: fix imbalanced css_get and css_put pair for shared mappings
On 2021/3/13 3:09, Mike Kravetz wrote:
> On 3/1/21 4:05 AM, Miaohe Lin wrote:
>> The current implementation of hugetlb_cgroup for shared mappings could have
>> different behavior. Consider the following two scenarios:
>>
>> 1.Assume initial css reference count of hugetlb_cgroup is 1:
>> 1.1 Call hugetlb_reserve_pages with from = 1, to = 2. So css reference
>> count is 2 associated with 1 file_region.
>> 1.2 Call hugetlb_reserve_pages with from = 2, to = 3. So css reference
>> count is 3 associated with 2 file_region.
>> 1.3 coalesce_file_region will coalesce these two file_regions into one.
>> So css reference count is 3 associated with 1 file_region now.
>>
>> 2.Assume initial css reference count of hugetlb_cgroup is 1 again:
>> 2.1 Call hugetlb_reserve_pages with from = 1, to = 3. So css reference
>> count is 2 associated with 1 file_region.
>>
>> Therefore, we might have one file_region while holding one or more css
>> reference counts. This inconsistency could lead to imbalanced css_get()
>> and css_put() pair. If we do css_put one by one (i.g. hole punch case),
>> scenario 2 would put one more css reference. If we do css_put all together
>> (i.g. truncate case), scenario 1 will leak one css reference.
>>
>> The imbalanced css_get() and css_put() pair would result in a non-zero
>> reference when we try to destroy the hugetlb cgroup. The hugetlb cgroup
>> directory is removed __but__ associated resource is not freed. This might
>> result in OOM or can not create a new hugetlb cgroup in a busy workload
>> ultimately.
>>
>> In order to fix this, we have to make sure that one file_region must hold
>> and only hold one css reference. So in coalesce_file_region case, we should
>
> I think this would sound/read better if stated as:
> ... one file_region must hold exactly one css reference ...
>
> This phrase is repeated in comments throughout the patch.
>
>> release one css reference before coalescence. Also only put css reference
>> when the entire file_region is removed.
>>
>> The last thing to note is that the caller of region_add() will only hold
>> one reference to h_cg->css for the whole contiguous reservation region.
>> But this area might be scattered when there are already some file_regions
>> reside in it. As a result, many file_regions may share only one h_cg->css
>> reference. In order to ensure that one file_region must hold and only hold
>> one h_cg->css reference, we should do css_get() for each file_region and
>> release the reference held by caller when they are done.
>
> Thanks for adding this to the commit message.
>
>>
>> Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings")
>> Reported-by: kernel test robot (auto build test ERROR)
>> Signed-off-by: Miaohe Lin
>> Cc: sta...@kernel.org
>> ---
>> v1->v2:
>> Fix auto build test ERROR when CGROUP_HUGETLB is disabled.
>> ---
>> include/linux/hugetlb_cgroup.h | 15 ++--
>> mm/hugetlb.c | 42 ++
>> mm/hugetlb_cgroup.c| 11 +++--
>> 3 files changed, 60 insertions(+), 8 deletions(-)
>
> Just a few minor nits below, all in comments. It is not required, but
> would be nice to update these. Code looks good.
>
Many thanks for review! I will fix all this nits. Should I resend this patch or
send another
one to fix this? Just let me know which is the easiest one for you.
Thanks again. :)
> Reviewed-by: Mike Kravetz
>
>>
>> diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
>> index 2ad6e92f124a..0bff345c4bc6 100644
>> --- a/include/linux/hugetlb_cgroup.h
>> +++ b/include/linux/hugetlb_cgroup.h
>> @@ -113,6 +113,11 @@ static inline bool hugetlb_cgroup_disabled(void)
>> return !cgroup_subsys_enabled(hugetlb_cgrp_subsys);
>> }
>>
>> +static inline void hugetlb_cgroup_put_rsvd_cgroup(struct hugetlb_cgroup
>> *h_cg)
>> +{
>> +css_put(&h_cg->css);
>> +}
>> +
>> extern int hugetlb_cgroup_charge_cgroup(int idx, unsigned long nr_pages,
>> struct hugetlb_cgroup **ptr);
>> extern int hugetlb_cgroup_charge_cgroup_rsvd(int idx, unsigned long
>> nr_pages,
>> @@ -138,7 +143,8 @@ extern void hugetlb_cgroup_uncharge_counter(struct
>> resv_map *resv,
>>
>> extern void hugetlb_cgroup_uncharge_file_region(struct resv_map *resv,
>> struct file_region *rg,
>> -unsigned long nr_pages);
>> +unsigned long nr_pages,
>> +bool region_del);
>>
>> extern void hugetlb_cgroup_file_init(void) __init;
>> extern void hugetlb_cgroup_migrate(struct page *oldhpage,
>> @@ -147,7 +153,8 @@ extern void hugetlb_cgroup_migrate(struct page *oldhpage,
>> #else
>> static inline void hugetlb_cgroup_uncharge_file_region(struct resv_map
>> *resv,
>> struct file_regio
Re: [PATCH v4] perf annotate: Fix sample events lost in stdio mode
On Sat, Mar 13, 2021 at 11:16 AM Yang Jihong wrote:
>
> In hist__find_annotations function, since different hist_entry may point to
> same
> symbol, we free notes->src to signal already processed this symbol in stdio
> mode;
> when annotate, entry will skipped if notes->src is NULL to avoid repeated
> output.
>
> However, there is a problem, for example, run the following command:
>
> # perf record -e branch-misses -e branch-instructions -a sleep 1
>
> perf.data file contains different types of sample event.
>
> If the same IP sample event exists in branch-misses and branch-instructions,
> this event uses the same symbol. When annotate branch-misses events,
> notes->src
> corresponding to this event is set to null, as a result, when annotate
> branch-instructions events, this event is skipped and no annotate is output.
>
> Solution of this patch is to remove zfree in hists__find_annotations and
> change sort order to "dso,symbol" to avoid duplicate output when different
> processes correspond to the same symbol.
Looks good. But I'm not sure about the branch stack mode.
I suspect we can use the same sort key there.
Jin Yao, what do you think?
Thanks,
Namhyung
> ---
> tools/perf/builtin-annotate.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
> index a23ba6bb99b6..ad169e3e2e8f 100644
> --- a/tools/perf/builtin-annotate.c
> +++ b/tools/perf/builtin-annotate.c
> @@ -374,13 +374,6 @@ static void hists__find_annotations(struct hists *hists,
> } else {
> hist_entry__tty_annotate(he, evsel, ann);
> nd = rb_next(nd);
> - /*
> -* Since we have a hist_entry per IP for the same
> -* symbol, free he->ms.sym->src to signal we already
> -* processed this symbol.
> -*/
> - zfree(¬es->src->cycles_hist);
> - zfree(¬es->src);
> }
> }
> }
> @@ -624,6 +617,12 @@ int cmd_annotate(int argc, const char **argv)
> if (setup_sorting(annotate.session->evlist) < 0)
> usage_with_options(annotate_usage, options);
> } else {
> + /*
> +* Events of different processes may correspond to the same
> +* symbol, we do not care about the processes in annotate,
> +* set sort order to avoid repeated output.
> +*/
> + sort_order = "dso,symbol";
> if (setup_sorting(NULL) < 0)
> usage_with_options(annotate_usage, options);
> }
> --
> 2.30.GIT
>
Re: [PATCH V2] cpufreq: Rudimentary typos fix in the file s5pv210-cpufreq.c
On Fri, Mar 12, 2021 at 04:57:07PM -0800, Randy Dunlap wrote:
> On 3/12/21 4:50 PM, Bhaskar Chowdhury wrote:
> > On 17:16 Fri 12 Mar 2021, Tom Saeger wrote:
> >> On Sat, Mar 13, 2021 at 04:56:21AM +0530, Bhaskar Chowdhury wrote:
> >>
> >> sent a few additional typo fixes to your V1, can you add those to your
> >> patch?
> >>
> >> Regards,
> >>
> >> --Tom
> >
> > Thanks, I have already sent out a V2 in public...I might make a V3 with your
> > changes too...did you sent it to ???
>
> It was just a reply to your v1 patch.
>
> --
> ~Randy
>
Bhaskar,
Here you go...
V2 additions:
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index af1ac3f6e4b8..73110b005716 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -91,7 +91,7 @@ static DEFINE_MUTEX(set_freq_lock);
/* Use 800MHz when entering sleep mode */
#define SLEEP_FREQ (800 * 1000)
-/* Tracks if cpu freqency can be updated anymore */
+/* Tracks if cpu frequency can be updated anymore */
static bool no_cpufreq_access;
/*
@@ -190,7 +190,7 @@ static u32 clkdiv_val[5][11] = {
/*
* This function set DRAM refresh counter
- * accoriding to operating frequency of DRAM
+ * according to operating frequency of DRAM
* ch: DMC port number 0 or 1
* freq: Operating frequency of DRAM(KHz)
*/
@@ -320,7 +320,7 @@ static int s5pv210_target(struct cpufreq_policy *policy,
unsigned int index)
/*
* 3. DMC1 refresh count for 133Mhz if (index == L4) is
-* true refresh counter is already programed in upper
+* true refresh counter is already programmed in upper
* code. 0x287@83Mhz
*/
if (!bus_speed_changing)
Re: [PATCH 4/5] mm/hugetlb: simplify the code when alloc_huge_page() failed in hugetlb_no_page()
On 2021/3/13 3:58, Mike Kravetz wrote:
> On 3/8/21 3:28 AM, Miaohe Lin wrote:
>> Rework the error handling code when alloc_huge_page() failed to remove some
>> duplicated code and simplify the code slightly.
>>
>> Signed-off-by: Miaohe Lin
>> ---
>> mm/hugetlb.c | 9 +++--
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 695603071f2c..69b8de866a24 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4337,13 +4337,10 @@ static vm_fault_t hugetlb_no_page(struct mm_struct
>> *mm,
>> * sure there really is no pte entry.
>> */
>> ptl = huge_pte_lock(h, mm, ptep);
>> -if (!huge_pte_none(huge_ptep_get(ptep))) {
>> -ret = 0;
>> -spin_unlock(ptl);
>> -goto out;
>> -}
>> +ret = 0;
>> +if (huge_pte_none(huge_ptep_get(ptep)))
>> +ret = vmf_error(PTR_ERR(page));
>
> This new code is simpler.
>
> The !huge_pte_none() catches an unlikely race. IMO, the existing code
> made that very clear. Would have been even more clear with an unlikely
> modifier. In any case, the lengthy comment above this code makes it
> clear why the check is there. Code changes are fine.
>
Yep, the lengthy comment above this code makes it much clear why we need the
check.
Thanks for carefully review! :)
> Reviewed-by: Mike Kravetz
>
[PATCH] cpufreq: cppc: simplify default delay_us setting
Simplify case when setting default in cppc_cpufreq_get_transition_delay_us.
Signed-off-by: Tom Saeger
---
drivers/cpufreq/cppc_cpufreq.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 8a482c434ea6..2f769b1630c5 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -216,26 +216,16 @@ static unsigned int
cppc_cpufreq_get_transition_delay_us(unsigned int cpu)
{
unsigned long implementor = read_cpuid_implementor();
unsigned long part_num = read_cpuid_part_number();
- unsigned int delay_us = 0;
switch (implementor) {
case ARM_CPU_IMP_QCOM:
switch (part_num) {
case QCOM_CPU_PART_FALKOR_V1:
case QCOM_CPU_PART_FALKOR:
- delay_us = 1;
- break;
- default:
- delay_us = cppc_get_transition_latency(cpu) /
NSEC_PER_USEC;
- break;
+ return 1;
}
- break;
- default:
- delay_us = cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
- break;
}
-
- return delay_us;
+ return cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
}
#else
--
2.30.1
Re: [PATCH] libbpf: Use the correct fd when attaching to perf events
On Fri, Mar 12, 2021 at 6:43 PM Sultan Alsawaf wrote:
>
> On Fri, Mar 12, 2021 at 06:33:01PM -0800, Andrii Nakryiko wrote:
> > On Fri, Mar 12, 2021 at 6:22 PM Sultan Alsawaf
> > wrote:
> > >
> > > On Fri, Mar 12, 2021 at 05:31:14PM -0800, Andrii Nakryiko wrote:
> > > > On Fri, Mar 12, 2021 at 1:43 PM Sultan Alsawaf
> > > > wrote:
> > > > >
> > > > > From: Sultan Alsawaf
> > > > >
> > > > > We should be using the program fd here, not the perf event fd.
> > > >
> > > > Why? Can you elaborate on what issue you ran into with the current code?
> > >
> > > bpf_link__pin() would fail with -EINVAL when using tracepoints, kprobes,
> > > or
> > > uprobes. The failure would happen inside the kernel, in
> > > bpf_link_get_from_fd()
> > > right here:
> > > if (f.file->f_op != &bpf_link_fops) {
> > > fdput(f);
> > > return ERR_PTR(-EINVAL);
> > > }
> >
> > kprobe/tracepoint/perf_event attachments behave like bpf_link (so
> > libbpf uses user-space high-level bpf_link APIs for it), but they are
> > not bpf_link-based in the kernel. So bpf_link__pin() won't work for
> > such types of programs until we actually have bpf_link-backed
> > attachment support in the kernel itself. I never got to implementing
> > this because we already had auto-detachment properties from perf_event
> > FD itself. But it would be nice to have that done as a real bpf_link
> > in the kernel (with all the observability, program update,
> > force-detach support).
> >
> > Looking for volunteers to make this happen ;)
> >
> >
> > >
> > > Since bpf wasn't looking for the perf event fd, I swapped it for the
> > > program fd
> > > and bpf_link__pin() worked.
> >
> > But you were pinning the BPF program, not a BPF link. Which is not
> > what should have happen.
>
> This is the code in question:
> link = bpf_program__attach(prog);
> // make sure `link` is valid, blah blah...
> bpf_link__pin(link, some_path);
>
> Are you saying that this usage is incorrect?
Right, for kprobe/tracepoint/perf_event attachments it's not
supported. cgroup, xdp, raw_tracepoint and
fentry/fexit/fmod_ret/freplace (and a few more) attachments are
bpf_links in the kernel, so it works for them.
>
> Sultan
Re: [PATCH 5/5] mm/hugetlb: avoid calculating fault_mutex_hash in truncate_op case
Hi:
On 2021/3/13 4:03, Mike Kravetz wrote:
> On 3/8/21 3:28 AM, Miaohe Lin wrote:
>> The fault_mutex hashing overhead can be avoided in truncate_op case because
>> page faults can not race with truncation in this routine. So calculate hash
>> for fault_mutex only in !truncate_op case to save some cpu cycles.
>>
>> Signed-off-by: Miaohe Lin
>> ---
>> fs/hugetlbfs/inode.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>> index c262566f7c5d..d81f52b87bd7 100644
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -482,10 +482,9 @@ static void remove_inode_hugepages(struct inode *inode,
>> loff_t lstart,
>>
>> for (i = 0; i < pagevec_count(&pvec); ++i) {
>> struct page *page = pvec.pages[i];
>> -u32 hash;
>> +u32 hash = 0;
>
> Do we need to initialize hash here?
> I would not bring this up normally, but the purpose of the patch is to save
> cpu cycles.
The hash is initialized here in order to avoid false positive
"uninitialized local variable used" warning. Or this is indeed unnecessary?
Many thanks for review.
>
Re: [PATCH] perf-stat: introduce bperf, share hardware PMCs with BPF
On Sat, Mar 13, 2021 at 12:38 AM Song Liu wrote: > > > > > On Mar 12, 2021, at 12:36 AM, Namhyung Kim wrote: > > > > Hi, > > > > On Fri, Mar 12, 2021 at 11:03 AM Song Liu wrote: > >> > >> perf uses performance monitoring counters (PMCs) to monitor system > >> performance. The PMCs are limited hardware resources. For example, > >> Intel CPUs have 3x fixed PMCs and 4x programmable PMCs per cpu. > >> > >> Modern data center systems use these PMCs in many different ways: > >> system level monitoring, (maybe nested) container level monitoring, per > >> process monitoring, profiling (in sample mode), etc. In some cases, > >> there are more active perf_events than available hardware PMCs. To allow > >> all perf_events to have a chance to run, it is necessary to do expensive > >> time multiplexing of events. > >> > >> On the other hand, many monitoring tools count the common metrics (cycles, > >> instructions). It is a waste to have multiple tools create multiple > >> perf_events of "cycles" and occupy multiple PMCs. > >> > >> bperf tries to reduce such wastes by allowing multiple perf_events of > >> "cycles" or "instructions" (at different scopes) to share PMUs. Instead > >> of having each perf-stat session to read its own perf_events, bperf uses > >> BPF programs to read the perf_events and aggregate readings to BPF maps. > >> Then, the perf-stat session(s) reads the values from these BPF maps. > >> > >> Please refer to the comment before the definition of bperf_ops for the > >> description of bperf architecture. > > > > Interesting! Actually I thought about something similar before, > > but my BPF knowledge is outdated. So I need to catch up but > > failed to have some time for it so far. ;-) > > > >> > >> bperf is off by default. To enable it, pass --use-bpf option to perf-stat. > >> bperf uses a BPF hashmap to share information about BPF programs and maps > >> used by bperf. This map is pinned to bpffs. The default address is > >> /sys/fs/bpf/bperf_attr_map. The user could change the address with option > >> --attr-map. > >> > >> --- > >> Known limitations: > >> 1. Do not support per cgroup events; > >> 2. Do not support monitoring of BPF program (perf-stat -b); > >> 3. Do not support event groups. > > > > In my case, per cgroup event counting is very important. > > And I'd like to do that with lots of cpus and cgroups. > > We can easily extend this approach to support cgroups events. I didn't > implement it to keep the first version simple. OK. > > > So I'm working on an in-kernel solution (without BPF), > > I hope to share it soon. > > This is interesting! I cannot wait to see how it looks like. I spent > quite some time try to enable in kernel sharing (not just cgroup > events), but finally decided to try BPF approach. Well I found it hard to support generic event sharing that works for all use cases. So I'm focusing on the per cgroup case only. > > > > > And for event groups, it seems the current implementation > > cannot handle more than one event (not even in a group). > > That could be a serious limitation.. > > It supports multiple events. Multiple events are independent, i.e., > "cycles" and "instructions" would use two independent leader programs. OK, then do you need multiple bperf_attr_maps? Does it work for an arbitrary number of events? > > > > >> > >> The following commands have been tested: > >> > >> perf stat --use-bpf -e cycles -a > >> perf stat --use-bpf -e cycles -C 1,3,4 > >> perf stat --use-bpf -e cycles -p 123 > >> perf stat --use-bpf -e cycles -t 100,101 > > > > Hmm... so it loads both leader and follower programs if needed, right? > > Does it support multiple followers with different targets at the same time? > > Yes, the whole idea is to have one leader program and multiple follower > programs. If we only run one of these commands at a time, it will load > one leader and one follower. If we run multiple of them in parallel, > they will share the same leader program and load multiple follower > programs. > > I actually tested more than the commands above. The list actually means > we support -a, -C -p, and -t. > > Currently, this works for multiple events, and different parallel > perf-stat. The two commands below will work well in parallel: > > perf stat --use-bpf -e ref-cycles,instructions -a > perf stat --use-bpf -e ref-cycles,cycles -C 1,3,5 > > Note the use of ref-cycles, which can only use one counter on Intel CPUs. > With this approach, the above two commands will not do time multiplexing > on ref-cycles. Awesome! Thanks, Namhyung
[PATCH RFC] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc
Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
flag set, but queue discipline by-pass does not work for lockless
qdisc because skb is always enqueued to qdisc even when the qdisc
is empty, see __dev_xmit_skb().
This patch calles sch_direct_xmit() to transmit the skb directly
to the driver for empty lockless qdisc too, which aviod enqueuing
and dequeuing operation. qdisc->empty is set to false whenever a
skb is enqueued, and is set to true when skb dequeuing return NULL,
see pfifo_fast_dequeue().
Also, qdisc is scheduled at the end of qdisc_run_end() when q->empty
is false to avoid packet stuck problem.
The performance for ip_forward test increases about 10% with this
patch.
Signed-off-by: Yunsheng Lin
---
include/net/sch_generic.h | 7 +--
net/core/dev.c| 11 +++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 2d6eb60..6591356 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -161,7 +161,6 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc)
if (qdisc->flags & TCQ_F_NOLOCK) {
if (!spin_trylock(&qdisc->seqlock))
return false;
- WRITE_ONCE(qdisc->empty, false);
} else if (qdisc_is_running(qdisc)) {
return false;
}
@@ -176,8 +175,12 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc)
static inline void qdisc_run_end(struct Qdisc *qdisc)
{
write_seqcount_end(&qdisc->running);
- if (qdisc->flags & TCQ_F_NOLOCK)
+ if (qdisc->flags & TCQ_F_NOLOCK) {
spin_unlock(&qdisc->seqlock);
+
+ if (unlikely(!READ_ONCE(qdisc->empty)))
+ __netif_schedule(qdisc);
+ }
}
static inline bool qdisc_may_bulk(const struct Qdisc *qdisc)
diff --git a/net/core/dev.c b/net/core/dev.c
index 2bfdd52..fa8504d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3791,7 +3791,18 @@ static inline int __dev_xmit_skb(struct sk_buff *skb,
struct Qdisc *q,
qdisc_calculate_pkt_len(skb, q);
if (q->flags & TCQ_F_NOLOCK) {
+ if (q->flags & TCQ_F_CAN_BYPASS && READ_ONCE(q->empty) &&
qdisc_run_begin(q)) {
+ qdisc_bstats_cpu_update(q, skb);
+
+ if (sch_direct_xmit(skb, q, dev, txq, NULL, true) &&
!READ_ONCE(q->empty))
+ __qdisc_run(q);
+
+ qdisc_run_end(q);
+ return NET_XMIT_SUCCESS;
+ }
+
rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
+ WRITE_ONCE(q->empty, false);
qdisc_run(q);
if (unlikely(to_free))
--
2.7.4
Re: [PATCH] libbpf: Use the correct fd when attaching to perf events
On Fri, Mar 12, 2021 at 06:33:01PM -0800, Andrii Nakryiko wrote:
> On Fri, Mar 12, 2021 at 6:22 PM Sultan Alsawaf wrote:
> >
> > On Fri, Mar 12, 2021 at 05:31:14PM -0800, Andrii Nakryiko wrote:
> > > On Fri, Mar 12, 2021 at 1:43 PM Sultan Alsawaf
> > > wrote:
> > > >
> > > > From: Sultan Alsawaf
> > > >
> > > > We should be using the program fd here, not the perf event fd.
> > >
> > > Why? Can you elaborate on what issue you ran into with the current code?
> >
> > bpf_link__pin() would fail with -EINVAL when using tracepoints, kprobes, or
> > uprobes. The failure would happen inside the kernel, in
> > bpf_link_get_from_fd()
> > right here:
> > if (f.file->f_op != &bpf_link_fops) {
> > fdput(f);
> > return ERR_PTR(-EINVAL);
> > }
>
> kprobe/tracepoint/perf_event attachments behave like bpf_link (so
> libbpf uses user-space high-level bpf_link APIs for it), but they are
> not bpf_link-based in the kernel. So bpf_link__pin() won't work for
> such types of programs until we actually have bpf_link-backed
> attachment support in the kernel itself. I never got to implementing
> this because we already had auto-detachment properties from perf_event
> FD itself. But it would be nice to have that done as a real bpf_link
> in the kernel (with all the observability, program update,
> force-detach support).
>
> Looking for volunteers to make this happen ;)
>
>
> >
> > Since bpf wasn't looking for the perf event fd, I swapped it for the
> > program fd
> > and bpf_link__pin() worked.
>
> But you were pinning the BPF program, not a BPF link. Which is not
> what should have happen.
This is the code in question:
link = bpf_program__attach(prog);
// make sure `link` is valid, blah blah...
bpf_link__pin(link, some_path);
Are you saying that this usage is incorrect?
Sultan
Re: [PATCH v5] do_wait: make PIDTYPE_PID case O(1) instead of O(n)
Here are the micro-benchmark results. I ended up reworking it to use
google's benchmark tool [1]. For each N I timed how long it took to fork
a new child and then immediately wait on it, while already having N
other children. (Initially I tried to vfork, but that didn't play nicely
with the benchmark tool)
[1] https://github.com/google/benchmark
Without the patch:
./bench_waitpid
2021-03-12T20:03:57-06:00
Running ./bench_waitpid
Run on (4 X 2693.88 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x4)
L1 Instruction 32 KiB (x4)
L2 Unified 4096 KiB (x4)
L3 Unified 16384 KiB (x4)
Load Average: 0.48, 0.16, 0.06
--
BenchmarkTime CPU Iterations
--
BM_WaitPid/1313354 ns74754 ns 8575
BM_WaitPid/10 305954 ns72424 ns 7977
BM_WaitPid/100 323126 ns83368 ns 7861
BM_WaitPid/500 324479 ns99071 ns 6541
BM_WaitPid/1000 377143 ns 178590 ns 3260
BM_WaitPid/5000 816597 ns 803919 ns 849
BM_WaitPid/80001282339 ns 1268179 ns 548
For example, this means that for a process that already has 5000
children, forking and then immediately calling waitpid on 5001st took an
average of 179 microsecs. The O(n) implementation starts getting
noticeably slower with around 100 children.
With the patch:
$ ./bench_waitpid
2021-03-12T20:19:52-06:00
Running ./bench_waitpid
Run on (4 X 2693.88 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x4)
L1 Instruction 32 KiB (x4)
L2 Unified 4096 KiB (x4)
L3 Unified 16384 KiB (x4)
Load Average: 1.39, 0.49, 0.18
--
BenchmarkTime CPU Iterations
--
BM_WaitPid/1305501 ns74028 ns 9261
BM_WaitPid/10 309644 ns74916 ns 8838
BM_WaitPid/100 319457 ns77193 ns 8717
BM_WaitPid/500 306929 ns73863 ns 8327
BM_WaitPid/1000 310849 ns74848 ns 8458
BM_WaitPid/5000 329324 ns79386 ns 9123
BM_WaitPid/8000 317991 ns77889 ns 7526
As expected, the cost is about the same as the baseline for a small
number of children, and stays about the same as the # of children increase.
Source:
#include
#include
#include
#include
#include
#include
#include "benchmark/benchmark.h"
static void BM_WaitPid(benchmark::State& state) {
int num_children = state.range(0);
// Create num_children
std::vector children;
children.reserve(num_children);
for (int i = 0; i < num_children; ++i) {
pid_t forkrv = fork();
if (forkrv < 0) {
perror("fork");
exit(1);
}
if (forkrv == 0) {
// child
exit(0);
}
children.push_back(forkrv);
}
// The body of this loop is what gets timed.
for (auto _ : state) {
pid_t forkrv = fork();
if (forkrv < 0) {
perror("fork");
exit(1);
}
if (forkrv == 0) {
// child
exit(0);
}
if (waitpid(forkrv, NULL, 0) < 0) {
perror("waitpid");
exit(1);
}
}
// Tear down the other children
for (pid_t child : children) {
if (waitpid(child, NULL, 0) < 0) {
perror("waitpid");
exit(1);
}
}
}
// Register the function as a benchmark
BENCHMARK(BM_WaitPid)->Arg(1)->Arg(10)->Arg(100)->Arg(500)->Arg(1000)->Arg(5000)->Arg(8000);
// Run the benchmark
BENCHMARK_MAIN();
[PATCH] usb: cdns3: delete repeated clear operations
dma_alloc_coherent already zeroes out memory, so memset is not needed. Signed-off-by: Wang Qing --- drivers/usb/cdns3/cdnsp-mem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/cdns3/cdnsp-mem.c b/drivers/usb/cdns3/cdnsp-mem.c index 7a84e92..1d1b9a4 --- a/drivers/usb/cdns3/cdnsp-mem.c +++ b/drivers/usb/cdns3/cdnsp-mem.c @@ -1231,7 +1231,6 @@ int cdnsp_mem_init(struct cdnsp_device *pdev) if (!pdev->dcbaa) return -ENOMEM; - memset(pdev->dcbaa, 0, sizeof(*pdev->dcbaa)); pdev->dcbaa->dma = dma; cdnsp_write_64(dma, &pdev->op_regs->dcbaa_ptr); -- 2.7.4
[PATCH] scsi: qla2xxx: use dma_pool_zalloc instead
use dma_pool_zalloc instead of dma_pool_alloc and memset
Signed-off-by: Wang Qing
---
drivers/scsi/qla2xxx/qla_os.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 0743925..ac5e954
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4238,11 +4238,10 @@ qla2x00_mem_alloc(struct qla_hw_data *ha, uint16_t
req_len, uint16_t rsp_len,
/* Get consistent memory allocated for Special Features-CB. */
if (IS_QLA27XX(ha) || IS_QLA28XX(ha)) {
- ha->sf_init_cb = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL,
+ ha->sf_init_cb = dma_pool_zalloc(ha->s_dma_pool, GFP_KERNEL,
&ha->sf_init_cb_dma);
if (!ha->sf_init_cb)
goto fail_sf_init_cb;
- memset(ha->sf_init_cb, 0, sizeof(struct init_sf_cb));
ql_dbg_pci(ql_dbg_init, ha->pdev, 0x0199,
"sf_init_cb=%p.\n", ha->sf_init_cb);
}
--
2.7.4
Re: [RFC PATCH v2 07/11] dma-mapping: Add flags to dma_map_ops to indicate PCI P2PDMA support
On Thu, Mar 11, 2021 at 04:31:37PM -0700, Logan Gunthorpe wrote:
> +int dma_pci_p2pdma_supported(struct device *dev)
^^^
bool?
> +{
> + const struct dma_map_ops *ops = get_dma_ops(dev);
> +
> + return !ops || ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED;
Is this logic correct? I would have expected.
return (ops && ops->flags & DMA_F_PCI_P2PDMA_SUPPORTED);
Ira
Re: [PATCH 4/4] integrity: Load mokx variables into the blacklist keyring
> On Mar 12, 2021, at 4:53 PM, Dimitri John Ledkov
> wrote:
>
> On 12/03/2021 21:49, Eric Snowberg wrote:
>>
>>> On Mar 12, 2021, at 11:39 AM, Dimitri John Ledkov
>>> wrote:
>>>
>>> On 25/02/2021 20:59, David Howells wrote:
From: Eric Snowberg
During boot the Secure Boot Forbidden Signature Database, dbx,
is loaded into the blacklist keyring. Systems booted with shim
have an equivalent Forbidden Signature Database called mokx.
Currently mokx is only used by shim and grub, the contents are
ignored by the kernel.
Add the ability to load mokx into the blacklist keyring during boot.
Signed-off-by: Eric Snowberg
Suggested-by: James Bottomley
Signed-off-by: David Howells
cc: Jarkko Sakkinen
Link:
https://lore.kernel.org/r/20210122181054.32635-5-eric.snowb...@oracle.com/
# v5
Link:
https://lore.kernel.org/r/c33c8e3839a41e9654f41cc92c7231104931b1d7.ca...@hansenpartnership.com/
---
security/integrity/platform_certs/load_uefi.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c
b/security/integrity/platform_certs/load_uefi.c
index ee4b4c666854..f290f78c3f30 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -132,8 +132,9 @@ static int __init load_moklist_certs(void)
static int __init load_uefi_certs(void)
{
efi_guid_t secure_var = EFI_IMAGE_SECURITY_DATABASE_GUID;
- void *db = NULL, *dbx = NULL;
- unsigned long dbsize = 0, dbxsize = 0;
+ efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
+ void *db = NULL, *dbx = NULL, *mokx = NULL;
+ unsigned long dbsize = 0, dbxsize = 0, mokxsize = 0;
efi_status_t status;
int rc = 0;
@@ -175,6 +176,21 @@ static int __init load_uefi_certs(void)
kfree(dbx);
}
+ mokx = get_cert_list(L"MokListXRT", &mok_var, &mokxsize, &status);
+ if (!mokx) {
+ if (status == EFI_NOT_FOUND)
+ pr_debug("mokx variable wasn't found\n");
+ else
+ pr_info("Couldn't get mokx list\n");
+ } else {
+ rc = parse_efi_signature_list("UEFI:MokListXRT",
+mokx, mokxsize,
+get_handler_for_dbx);
+ if (rc)
+ pr_err("Couldn't parse mokx signatures %d\n", rc);
+ kfree(mokx);
+ }
+
>>>
>>>
>>> My preference would be if the above hunk was moved into the
>>> load_moklist_certs() function which is called just below. Such that
>>> loading of MokListRT & MOkListXRT are done next to each other.
>>>
>>> And also implement loading the same way it is done for MokListRT -
>>> specifically via the EFI MOKvar config table & then via a variable.
>>>
>>> See 726bd8965a5f112d9601f7ce68effa1e46e02bf2 otherwise large MokListXRT
>>> will fail to parse.
>>
>> Is this support available from shim now? Previously I thought only
>> MOK could be loaded from the config table, not MOKx.
>>
>
> It is about to become available across all distributions with the next
> shim as everyone is about to ship SBAT capable shims.
When I tested this change, I thought it was around 25+ certs and
hundreds of hashes before shim started having problems. Someone
needing the config list must really have a large list. It would
be nice of the MOKx in shim would support a TBS certificate hash,
it would really save space.
If MOKx will be available thru a config table in the next shim,
I’ll prepare a follow on patch to add this support.
> From my system with the next shim & 5.10 kernel I have:
>
> $ ls /sys/firmware/efi/mok-variables/
> MokIgnoreDB MokListRT MokListXRT MokSBStateRT SbatRT
>
> It's not just a single Mok variable, but _all_ mok variables are
> available from the mok-table that are used to determine mok state.
> Including whether or not db should be ignored, whether or not signature
> verification is turned off, and what are the SBAT generation revocations
> are, in addition to MokListRT & MokListXRT.
>
> For example, kernel could gain further functionality to honor the user
> choices and disable loading db controlled by MokIgnoreDB especially
> since shim chooses to not consider db certificates & hashes as trust-worthy.
Isn’t this already handled by uefi_check_ignore_db()?
Re: [PATCH v2 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
Hi, I'm not sure I can agree. Especially for regions like IPA and TZ-reserved, which seem the same on (almost?) all.. Sure, the configuration for various remoteprocs *can* differ based on what the vendor decided to go with, but more often than not (especially with phones) vendors just take a MTP or CDP design, add a screen, couple of cameras and call it their own (you can tell by how similar most of them to the original reference designs in DT). While this is usually the case with lower-end (so not exactly sdm845) devices, it also kinda applies here... I guess for this one, we should find the lowest common denominator and keep the nodes that are in the majority of devices in 845 DTSI and only alter them if need be.. For WoA devices that may stray further away, you can just add a label to reserved-memory and /delete-node/ it, so that you can rewrite it cleanly. The proposed approach just adds a lot - A LOT - of duplication. It will REALLY bite after more people submit 845-based phones, of which there are plenty (4 Xperias, a whole lot of Xiaomis, a couple of Samsungs, LGs... need I go on?). Konrad
Re: [PATCH] libbpf: Use the correct fd when attaching to perf events
On Fri, Mar 12, 2021 at 6:22 PM Sultan Alsawaf wrote:
>
> On Fri, Mar 12, 2021 at 05:31:14PM -0800, Andrii Nakryiko wrote:
> > On Fri, Mar 12, 2021 at 1:43 PM Sultan Alsawaf
> > wrote:
> > >
> > > From: Sultan Alsawaf
> > >
> > > We should be using the program fd here, not the perf event fd.
> >
> > Why? Can you elaborate on what issue you ran into with the current code?
>
> bpf_link__pin() would fail with -EINVAL when using tracepoints, kprobes, or
> uprobes. The failure would happen inside the kernel, in bpf_link_get_from_fd()
> right here:
> if (f.file->f_op != &bpf_link_fops) {
> fdput(f);
> return ERR_PTR(-EINVAL);
> }
kprobe/tracepoint/perf_event attachments behave like bpf_link (so
libbpf uses user-space high-level bpf_link APIs for it), but they are
not bpf_link-based in the kernel. So bpf_link__pin() won't work for
such types of programs until we actually have bpf_link-backed
attachment support in the kernel itself. I never got to implementing
this because we already had auto-detachment properties from perf_event
FD itself. But it would be nice to have that done as a real bpf_link
in the kernel (with all the observability, program update,
force-detach support).
Looking for volunteers to make this happen ;)
>
> Since bpf wasn't looking for the perf event fd, I swapped it for the program
> fd
> and bpf_link__pin() worked.
But you were pinning the BPF program, not a BPF link. Which is not
what should have happen.
>
> Sultan
Re: [RFC PATCH v2 04/11] PCI/P2PDMA: Introduce pci_p2pdma_should_map_bus() and pci_p2pdma_bus_offset()
On Thu, Mar 11, 2021 at 04:31:34PM -0700, Logan Gunthorpe wrote:
> Introduce pci_p2pdma_should_map_bus() which is meant to be called by
^
pci_p2pdma_dma_map_type() ???
FWIW I find this name confusing with pci_p2pdma_map_type() and looking at the
implementation I'm not clear why pci_p2pdma_dma_map_type() needs to exist?
Ira
[snip]
> +
> +/**
> + * pci_p2pdma_dma_map_type - determine if a DMA mapping should use the
> + * bus address, be mapped normally or fail
> + * @dev: device doing the DMA request
> + * @pgmap: dev_pagemap structure for the mapping
> + *
> + * Returns:
> + *1 - if the page should be mapped with a bus address,
> + *0 - if the page should be mapped normally through an IOMMU mapping or
> + *physical address; or
> + * -1 - if the device should not map the pages and an error should be
> + *returned
> + */
> +int pci_p2pdma_dma_map_type(struct device *dev, struct dev_pagemap *pgmap)
> +{
> + struct pci_p2pdma_pagemap *p2p_pgmap = to_p2p_pgmap(pgmap);
> + struct pci_dev *client;
> +
> + if (!dev_is_pci(dev))
> + return -1;
> +
> + client = to_pci_dev(dev);
> +
> + switch (pci_p2pdma_map_type(p2p_pgmap->provider, client)) {
> + case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> + return 0;
> + case PCI_P2PDMA_MAP_BUS_ADDR:
> + return 1;
> + default:
> + return -1;
> + }
> +}
> +EXPORT_SYMBOL_GPL(pci_p2pdma_dma_map_type);
I guess the main point here is to export this to the DMA layer?
Ira
[PATCH] mailbox: fix various typos in comments
Fix trivial typos in mailbox driver comments.
s/Intergrated/Integrated/
s/extenstion/extension/
s/atleast/at least/
s/commnunication/communication/
s/assgined/assigned/
s/commnunication/communication/
s/recevied/received/
s/succeded/succeeded/
s/implmentation/implementation/
s/definiation/definition/
s/traget/target/
s/wont/won't/
Cc: triv...@kernel.org
Signed-off-by: Tom Saeger
---
drivers/mailbox/Kconfig | 2 +-
drivers/mailbox/bcm-flexrm-mailbox.c| 4 ++--
drivers/mailbox/mailbox-xgene-slimpro.c | 6 +++---
drivers/mailbox/mailbox.h | 2 +-
drivers/mailbox/pcc.c | 2 +-
drivers/mailbox/pl320-ipc.c | 2 +-
drivers/mailbox/sprd-mailbox.c | 12 ++--
drivers/mailbox/ti-msgmgr.c | 2 +-
8 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index f4abe3529acd..68de2c6af727 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -78,7 +78,7 @@ config OMAP_MBOX_KFIFO_SIZE
module parameter).
config ROCKCHIP_MBOX
- bool "Rockchip Soc Intergrated Mailbox Support"
+ bool "Rockchip Soc Integrated Mailbox Support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
help
This driver provides support for inter-processor communication
diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c
b/drivers/mailbox/bcm-flexrm-mailbox.c
index bee33abb5308..b4f33dc399a0 100644
--- a/drivers/mailbox/bcm-flexrm-mailbox.c
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -423,7 +423,7 @@ static void flexrm_enqueue_desc(u32 nhpos, u32 nhcnt, u32
reqid,
*
* In general use, number of non-HEADER descriptors can easily go
* beyond 31. To tackle this situation, we have packet (or request)
-* extenstion bits (STARTPKT and ENDPKT) in the HEADER descriptor.
+* extension bits (STARTPKT and ENDPKT) in the HEADER descriptor.
*
* To use packet extension, the first HEADER descriptor of request
* (or packet) will have STARTPKT=1 and ENDPKT=0. The intermediate
@@ -1095,7 +1095,7 @@ static int flexrm_process_completions(struct flexrm_ring
*ring)
/*
* Get current completion read and write offset
*
-* Note: We should read completion write pointer atleast once
+* Note: We should read completion write pointer at least once
* after we get a MSI interrupt because HW maintains internal
* MSI status which will allow next MSI interrupt only after
* completion write pointer is read.
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c
b/drivers/mailbox/mailbox-xgene-slimpro.c
index de260799f1b9..5b3a2dcd5955 100644
--- a/drivers/mailbox/mailbox-xgene-slimpro.c
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -51,10 +51,10 @@ struct slimpro_mbox_chan {
/**
* X-Gene SlimPRO Mailbox controller data
*
- * X-Gene SlimPRO Mailbox controller has 8 commnunication channels.
- * Each channel has a separate IRQ number assgined to it.
+ * X-Gene SlimPRO Mailbox controller has 8 communication channels.
+ * Each channel has a separate IRQ number assigned to it.
*
- * @mb_ctrl: Representation of the commnunication channel controller
+ * @mb_ctrl: Representation of the communication channel controller
* @mc:Array of SlimPRO mailbox channels of the controller
* @chans: Array of mailbox communication channels
*
diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
index 4e3cc4426513..046d6d258b32 100644
--- a/drivers/mailbox/mailbox.h
+++ b/drivers/mailbox/mailbox.h
@@ -5,6 +5,6 @@
#define TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
#define TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
-#define TXDONE_BY_ACK BIT(2) /* S/W ACK recevied by Client ticks the TX */
+#define TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
#endif /* __MAILBOX_H */
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index ef9ecd1f5958..9cb1dcf47661 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -32,7 +32,7 @@
* * Client writes WRITE cmd in communication region cmd address.
* * Client issues mbox_send_message() which rings the PCC doorbell
* for its PCC channel.
- * * If command completes, then writes have succeded and it can release
+ * * If command completes, then writes have succeeded and it can release
* the channel lock.
*
* There is a Nominal latency defined for each channel which indicates
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index 25e0b6f7a10f..fbcf07930390 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -73,7 +73,7 @@ static u32 __ipc_rcv(int mbox, u32 *data)
return data[1];
}
-/* blocking implmentation from the A9 side, not usuable in interrupts! */
+/* blocking implementation from the A9 side, n
Re: [PATCH] perf annotate: Fix sample events lost in stdio mode
Hello,
On 2021/3/13 10:00, Yang Jihong wrote:
Hello, Namhyung
On 2021/3/12 18:20, Yang Jihong wrote:
Hello,
On 2021/3/12 16:39, Namhyung Kim wrote:
On Fri, Mar 12, 2021 at 4:19 PM Yang Jihong
wrote:
Hello,
On 2021/3/12 13:49, Namhyung Kim wrote:
Hi,
On Fri, Mar 12, 2021 at 12:24 PM Yang Jihong
wrote:
Hello, Namhyung
On 2021/3/11 22:42, Namhyung Kim wrote:
Hi,
On Thu, Mar 11, 2021 at 5:48 PM Yang Jihong
wrote:
Hello,
On 2021/3/6 16:28, Yang Jihong wrote:
In hist__find_annotations function, since have a hist_entry per
IP for the same
symbol, we free notes->src to signal already processed this
symbol in stdio mode;
when annotate, entry will skipped if notes->src is NULL to
avoid repeated output.
I'm not sure it's still true that we have a hist_entry per IP.
Afaik the default sort key is comm,dso,sym which means it should
have a single
hist_entry for each symbol. It seems like an old comment..
Emm, yes, we have a hist_entry for per IP.
a member named "sym" in struct "hist_entry" points to symbol,
different IP may point to the same symbol.
Are you sure about this? It seems like a bug then.
Yes, now each IP corresponds to a hist_entry :)
Last week I found that some sample events were missing when perf
annotate in stdio mode, so I went through the annotate code carefully.
The event handling process is as follows:
process_sample_event
evsel_add_sample
hists__add_entry
__hists__add_entry
hists__findnew_entry
hist_entry__new -> here allock new
hist_entry
Yeah, so this is for a symbol.
hist_entry__inc_addr_samples
symbol__inc_addr_samples
symbol__hists
annotated_source__new -> here alloc annotate
soruce
annotated_source__alloc_histograms -> here alloc histograms
This should be for each IP (ideally it should be per instruction).
By bugs, do you mean there's something wrong?
No. I think we were saying about different things. :)
OK, :)
diff --git a/tools/perf/builtin-annotate.c
b/tools/perf/builtin-annotate.c
index a23ba6bb99b6..a91fe45bd69f 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct
hists *hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
- /*
- * Since we have a hist_entry per IP for
the same
- * symbol, free he->ms.sym->src to signal
we already
- * processed this symbol.
- */
- zfree(¬es->src->cycles_hist);
- zfree(¬es->src);
}
}
}
This solution may have the following problem:
For example, if two sample events are in two different processes
but in
the same symbol, repeated output may occur.
Therefore, a flag is required to indicate whether the symbol has been
processed to avoid repeated output.
Hmm.. ok. Yeah we don't care about the processes here.
Then we should remove it from the sort key like below:
@@ -624,6 +617,7 @@ int cmd_annotate(int argc, const char **argv)
if (setup_sorting(annotate.session->evlist) < 0)
usage_with_options(annotate_usage, options);
} else {
+ sort_order = "dso,symbol";
if (setup_sorting(NULL) < 0)
usage_with_options(annotate_usage, options);
}
Are you referring to this solution?
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct hists
*hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
- /*
- * Since we have a hist_entry per IP for the
same
- * symbol, free he->ms.sym->src to signal we
already
- * processed this symbol.
- */
- zfree(¬es->src->cycles_hist);
- zfree(¬es->src);
}
}
}
@@ -624,6 +617,7 @@ int cmd_annotate(int argc, const char **argv)
if (setup_sorting(annotate.session->evlist) < 0)
usage_with_options(annotate_usage, options);
} else {
+ sort_order = "dso,symbol";
if (setup_sorting(NULL) < 0)
usage_with_options(annotate_usage, options);
}
It seems to be a better solution without adding new member.
I just tested it and it works.
If we decide to use this solution, I'll resubmit a v3 patch.
I prefer changing the sort order (and removing the zfree and comments).
OK, I'll submit a v3 patch based on th
Re: [PATCH] libbpf: Use the correct fd when attaching to perf events
On Fri, Mar 12, 2021 at 05:31:14PM -0800, Andrii Nakryiko wrote:
> On Fri, Mar 12, 2021 at 1:43 PM Sultan Alsawaf wrote:
> >
> > From: Sultan Alsawaf
> >
> > We should be using the program fd here, not the perf event fd.
>
> Why? Can you elaborate on what issue you ran into with the current code?
bpf_link__pin() would fail with -EINVAL when using tracepoints, kprobes, or
uprobes. The failure would happen inside the kernel, in bpf_link_get_from_fd()
right here:
if (f.file->f_op != &bpf_link_fops) {
fdput(f);
return ERR_PTR(-EINVAL);
}
Since bpf wasn't looking for the perf event fd, I swapped it for the program fd
and bpf_link__pin() worked.
Sultan
[PATCH 8/9] clk: qcom: gcc-msm8994: Add proper msm8992 support
MSM8992 is a cut-down version of MSM8994, featuring
largely the same hardware.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 70 +-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index fae784b4242f..a5b9db7678d1 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -220,6 +221,17 @@ static struct freq_tbl ftbl_blsp1_qup1_spi_apps_clk_src[]
= {
{ }
};
+static struct freq_tbl ftbl_blsp1_qup_spi_apps_clk_src_8992[] = {
+ F(96, P_XO, 10, 1, 2),
+ F(480, P_XO, 4, 0, 0),
+ F(960, P_XO, 2, 0, 0),
+ F(1500, P_GPLL0, 10, 1, 4),
+ F(1920, P_XO, 1, 0, 0),
+ F(2500, P_GPLL0, 12, 1, 2),
+ F(5000, P_GPLL0, 12, 0, 0),
+ { }
+};
+
static struct clk_rcg2 blsp1_qup1_spi_apps_clk_src = {
.cmd_rcgr = 0x064c,
.mnd_width = 8,
@@ -980,6 +992,18 @@ static struct freq_tbl ftbl_sdcc1_apps_clk_src[] = {
{ }
};
+static struct freq_tbl ftbl_sdcc1_apps_clk_src_8992[] = {
+ F(144000, P_XO, 16, 3, 25),
+ F(40, P_XO, 12, 1, 4),
+ F(2000, P_GPLL0, 15, 1, 2),
+ F(2500, P_GPLL0, 12, 1, 2),
+ F(5000, P_GPLL0, 12, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ F(17200, P_GPLL4, 2, 0, 0),
+ F(34400, P_GPLL4, 1, 0, 0),
+ { }
+};
+
static struct clk_rcg2 sdcc1_apps_clk_src = {
.cmd_rcgr = 0x04d0,
.mnd_width = 8,
@@ -2718,13 +2742,57 @@ static const struct qcom_cc_desc gcc_msm8994_desc = {
};
static const struct of_device_id gcc_msm8994_match_table[] = {
- { .compatible = "qcom,gcc-msm8994" },
+ { .compatible = "qcom,gcc-msm8992" },
+ { .compatible = "qcom,gcc-msm8994" }, /* V2 and V2.1 */
{}
};
MODULE_DEVICE_TABLE(of, gcc_msm8994_match_table);
static int gcc_msm8994_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ bool is_msm8992;
+
+ is_msm8992 = of_device_is_compatible(pdev->dev.of_node,
"qcom,gcc-msm8992");
+
+ if (is_msm8992) {
+ /* MSM8992 features less clocks and some have different freq
tables */
+ gcc_msm8994_desc.clks[GCC_LPASS_Q6_AXI_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_PCIE_1_AUX_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_PCIE_1_CFG_AHB_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_PCIE_1_MSTR_AXI_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_PCIE_1_PIPE_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_PCIE_1_SLV_AXI_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_SYS_NOC_UFS_AXI_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_AHB_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_AXI_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_RX_CFG_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_RX_SYMBOL_0_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_RX_SYMBOL_1_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_TX_CFG_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_TX_SYMBOL_0_CLK] = 0;
+ gcc_msm8994_desc.clks[GCC_UFS_TX_SYMBOL_1_CLK] = 0;
+ gcc_msm8994_desc.clks[PCIE_1_AUX_CLK_SRC] = 0;
+ gcc_msm8994_desc.clks[PCIE_1_PIPE_CLK_SRC] = 0;
+ gcc_msm8994_desc.clks[PCIE_1_PHY_LDO] = 0;
+ gcc_msm8994_desc.clks[UFS_AXI_CLK_SRC] = 0;
+ gcc_msm8994_desc.clks[UFS_PHY_LDO] = 0;
+
+ sdcc1_apps_clk_src.freq_tbl = ftbl_sdcc1_apps_clk_src_8992;
+ blsp1_qup1_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp1_qup2_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp1_qup3_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp1_qup4_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp1_qup5_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp1_qup6_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp2_qup1_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp2_qup2_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp2_qup3_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp2_qup4_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp2_qup5_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ blsp2_qup6_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
+ }
+
return qcom_cc_probe(pdev, &gcc_msm8994_desc);
}
--
2.30.2
[PATCH 9/9] clk: qcom: gcc-msm8994: Add a quirk for a different SDCC configuration
Some devices come with a different SDCC clock configuration,
account for that.
Signed-off-by: Konrad Dybcio
---
.../bindings/clock/qcom,gcc-msm8994.yaml | 4
drivers/clk/qcom/gcc-msm8994.c | 16
2 files changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
index f8067fb1bbd6..9db0800a4ee4 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
@@ -49,6 +49,10 @@ properties:
description:
Protected clock specifier list as per common clock binding.
+ qcom,sdcc2-clk-src-40mhz:
+description: SDCC2_APPS clock source runs at 40MHz.
+type: boolean
+
required:
- compatible
- reg
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index a5b9db7678d1..1fbbf5f5dee0 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -1018,6 +1018,19 @@ static struct clk_rcg2 sdcc1_apps_clk_src = {
},
};
+static struct freq_tbl ftbl_sdcc2_40mhz_apps_clk_src[] = {
+ F(144000, P_XO, 16, 3, 25),
+ F(40, P_XO, 12, 1, 4),
+ F(2000, P_GPLL0, 15, 1, 2),
+ F(2500, P_GPLL0, 12, 1, 2),
+ F(4000, P_GPLL0, 15, 0, 0),
+ F(5000, P_GPLL0, 12, 0, 0),
+ F(8000, P_GPLL0, 7.5, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ F(2, P_GPLL0, 3, 0, 0),
+ { }
+};
+
static struct freq_tbl ftbl_sdcc2_4_apps_clk_src[] = {
F(144000, P_XO, 16, 3, 25),
F(40, P_XO, 12, 1, 4),
@@ -2793,6 +2806,9 @@ static int gcc_msm8994_probe(struct platform_device *pdev)
blsp2_qup6_i2c_apps_clk_src.freq_tbl =
ftbl_blsp1_qup_spi_apps_clk_src_8992;
}
+ if (of_find_property(dev->of_node, "qcom,sdcc2-clk-src-40mhz", NULL))
+ sdcc2_apps_clk_src.freq_tbl = ftbl_sdcc2_40mhz_apps_clk_src;
+
return qcom_cc_probe(pdev, &gcc_msm8994_desc);
}
--
2.30.2
[PATCH 6/9] clk: qcom: gcc-msm8994: Remove the inexistent GDSC_PCIE
This GDSC is not present on msm8994.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index 962107b5f1af..e1e40982ebee 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -2493,14 +2493,6 @@ static struct clk_branch gcc_prng_ahb_clk = {
},
};
-static struct gdsc pcie_gdsc = {
- .gdscr = 0x1e18,
- .pd = {
- .name = "pcie",
- },
- .pwrsts = PWRSTS_OFF_ON,
-};
-
static struct gdsc pcie_0_gdsc = {
.gdscr = 0x1ac4,
.pd = {
@@ -2690,7 +2682,8 @@ static struct clk_regmap *gcc_msm8994_clocks[] = {
};
static struct gdsc *gcc_msm8994_gdscs[] = {
- [PCIE_GDSC] = &pcie_gdsc,
+ /* This GDSC does not exist, but ABI has to remain intact */
+ [PCIE_GDSC] = 0,
[PCIE_0_GDSC] = &pcie_0_gdsc,
[PCIE_1_GDSC] = &pcie_1_gdsc,
[USB30_GDSC] = &usb30_gdsc,
--
2.30.2
[PATCH 7/9] clk: qcom: gcc-msm8994: Add modem reset
This will be required to support the modem.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 1 +
include/dt-bindings/clock/qcom,gcc-msm8994.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index e1e40982ebee..fae784b4242f 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -2693,6 +2693,7 @@ static struct gdsc *gcc_msm8994_gdscs[] = {
static const struct qcom_reset_map gcc_msm8994_resets[] = {
[USB3_PHY_RESET] = { 0x1400 },
[USB3PHY_PHY_RESET] = { 0x1404 },
+ [MSS_RESET] = { 0x1680 },
[PCIE_PHY_0_RESET] = { 0x1b18 },
[PCIE_PHY_1_RESET] = { 0x1b98 },
[QUSB2_PHY_RESET] = { 0x04b8 },
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8994.h
b/include/dt-bindings/clock/qcom,gcc-msm8994.h
index dcb49817dcec..f6836f430bb5 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8994.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8994.h
@@ -174,5 +174,6 @@
#define PCIE_PHY_0_RESET 2
#define PCIE_PHY_1_RESET 3
#define QUSB2_PHY_RESET4
+#define MSS_RESET 5
#endif
--
2.30.2
[PATCH 4/9] clk: qcom: gcc-msm8994: Add missing NoC clocks
Add necessary NoC clocks to provide frequency sources for
relevant branch clocks.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 101 ---
include/dt-bindings/clock/qcom,gcc-msm8994.h | 3 +
2 files changed, 92 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index 0ebc827f0f05..f661e28ac14a 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -108,6 +108,42 @@ static const struct clk_parent_data gcc_xo_gpll0_gpll4[] =
{
{ .hw = &gpll4.clkr.hw },
};
+static struct clk_rcg2 system_noc_clk_src = {
+ .cmd_rcgr = 0x0120,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_map,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "system_noc_clk_src",
+ .parent_data = gcc_xo_gpll0,
+ .num_parents = ARRAY_SIZE(gcc_xo_gpll0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 config_noc_clk_src = {
+ .cmd_rcgr = 0x0150,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_map,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "config_noc_clk_src",
+ .parent_data = gcc_xo_gpll0,
+ .num_parents = ARRAY_SIZE(gcc_xo_gpll0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 periph_noc_clk_src = {
+ .cmd_rcgr = 0x0190,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_map,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "periph_noc_clk_src",
+ .parent_data = gcc_xo_gpll0,
+ .num_parents = ARRAY_SIZE(gcc_xo_gpll0),
+ .ops = &clk_rcg2_ops,
+ },
+};
+
static struct freq_tbl ftbl_ufs_axi_clk_src[] = {
F(5000, P_GPLL0, 12, 0, 0),
F(1, P_GPLL0, 6, 0, 0),
@@ -1097,6 +1133,8 @@ static struct clk_branch gcc_blsp1_ahb_clk = {
.enable_mask = BIT(17),
.hw.init = &(struct clk_init_data){
.name = "gcc_blsp1_ahb_clk",
+ .parent_hws = (const struct clk_hw *[]){
&periph_noc_clk_src.clkr.hw },
+ .num_parents = 1,
.ops = &clk_branch2_ops,
},
},
@@ -1380,6 +1418,8 @@ static struct clk_branch gcc_blsp2_ahb_clk = {
.enable_mask = BIT(15),
.hw.init = &(struct clk_init_data){
.name = "gcc_blsp2_ahb_clk",
+ .parent_hws = (const struct clk_hw *[]){
&periph_noc_clk_src.clkr.hw },
+ .num_parents = 1,
.ops = &clk_branch2_ops,
},
},
@@ -1707,6 +1747,8 @@ static struct clk_branch gcc_lpass_q6_axi_clk = {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_lpass_q6_axi_clk",
+ .parent_hws = (const struct clk_hw *[]){
&system_noc_clk_src.clkr.hw },
+ .num_parents = 1,
.ops = &clk_branch2_ops,
},
},
@@ -1719,6 +1761,8 @@ static struct clk_branch gcc_mss_q6_bimc_axi_clk = {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_mss_q6_bimc_axi_clk",
+ .parent_hws = (const struct clk_hw *[]){
&system_noc_clk_src.clkr.hw },
+ .num_parents = 1,
.ops = &clk_branch2_ops,
},
},
@@ -1746,6 +1790,9 @@ static struct clk_branch gcc_pcie_0_cfg_ahb_clk = {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_pcie_0_cfg_ahb_clk",
+ .parent_hws = (const struct clk_hw *[]){
&config_noc_clk_src.clkr.hw },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
.ops = &clk_branch2_ops,
},
},
@@ -1758,6 +1805,9 @@ static struct clk_branch gcc_pcie_0_mstr_axi_clk = {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_pcie_0_mstr_axi_clk",
+ .parent_hws = (const struct clk_hw *[]){
&system_noc_clk_src.clkr.hw },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
.ops = &clk_branch2_ops,
},
},
@@ -1787,6 +1837,9 @@ static struct clk_branch gcc_pcie_0_slv_axi_clk = {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_pcie_0_slv_axi_clk",
+ .parent_hws = (const struct clk_hw *[]){
&system_noc_clk_src.clkr.hw },
+ .num_
[PATCH 5/9] clk: qcom: gcc-msm8994: Add missing clocks
This should be the last "add missing clocks" commit, as to
my knowledge there are no more clocks registered within gcc.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 134 +++
include/dt-bindings/clock/qcom,gcc-msm8994.h | 9 ++
2 files changed, 143 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index f661e28ac14a..962107b5f1af 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -2327,6 +2327,19 @@ static struct clk_branch gcc_usb3_phy_aux_clk = {
},
};
+static struct clk_branch gcc_usb3_phy_pipe_clk = {
+ .halt_reg = 0x140c,
+ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x140c,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_usb3_phy_pipe_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_usb_hs_ahb_clk = {
.halt_reg = 0x0488,
.clkr = {
@@ -2368,6 +2381,118 @@ static struct clk_branch gcc_usb_phy_cfg_ahb2phy_clk = {
},
};
+static struct clk_branch gpll0_out_mmsscc = {
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x1484,
+ .enable_mask = BIT(26),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll0_out_mmsscc",
+ .parent_hws = (const struct clk_hw *[]){ &gpll0.clkr.hw
},
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gpll0_out_msscc = {
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x1484,
+ .enable_mask = BIT(27),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll0_out_msscc",
+ .parent_hws = (const struct clk_hw *[]){ &gpll0.clkr.hw
},
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch pcie_0_phy_ldo = {
+ .halt_reg = 0x1e00,
+ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x1E00,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "pcie_0_phy_ldo",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch pcie_1_phy_ldo = {
+ .halt_reg = 0x1e04,
+ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x1E04,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "pcie_1_phy_ldo",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch ufs_phy_ldo = {
+ .halt_reg = 0x1e0c,
+ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x1E0C,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "ufs_phy_ldo",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch usb_ss_phy_ldo = {
+ .halt_reg = 0x1e08,
+ .halt_check = BRANCH_HALT_SKIP,
+ .clkr = {
+ .enable_reg = 0x1E08,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "usb_ss_phy_ldo",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gcc_boot_rom_ahb_clk = {
+ .halt_reg = 0x0e04,
+ .halt_check = BRANCH_HALT_VOTED,
+ .hwcg_reg = 0x0e04,
+ .hwcg_bit = 1,
+ .clkr = {
+ .enable_reg = 0x1484,
+ .enable_mask = BIT(10),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_boot_rom_ahb_clk",
+ .parent_hws = (const struct clk_hw *[]){
&config_noc_clk_src.clkr.hw },
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gcc_prng_ahb_clk = {
+ .halt_reg = 0x0d04,
+ .halt_check = BRANCH_HALT_VOTED,
+ .clkr = {
+ .enable_reg = 0x1484,
+ .enable_mask = BIT(13),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_prng_ahb_clk",
+ .parent_hws = (const struct clk_hw *[]){
&periph_noc_clk_src.clkr.hw },
+ .num_parents = 1,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct gdsc pcie_gdsc = {
.gdscr = 0x1e18,
.pd =
[PATCH 2/9] clk: qcom: gcc-msm8994: Modernize the driver
Switch to the newer-style parent_data and remove the hardcoded
xo clock.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 868 -
1 file changed, 313 insertions(+), 555 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index 144d2ba7a9be..69241651b171 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -28,50 +28,18 @@ enum {
P_GPLL4,
};
-static const struct parent_map gcc_xo_gpll0_map[] = {
- { P_XO, 0 },
- { P_GPLL0, 1 },
-};
-
-static const char * const gcc_xo_gpll0[] = {
- "xo",
- "gpll0",
-};
-
-static const struct parent_map gcc_xo_gpll0_gpll4_map[] = {
- { P_XO, 0 },
- { P_GPLL0, 1 },
- { P_GPLL4, 5 },
-};
-
-static const char * const gcc_xo_gpll0_gpll4[] = {
- "xo",
- "gpll0",
- "gpll4",
-};
-
-static struct clk_fixed_factor xo = {
- .mult = 1,
- .div = 1,
- .hw.init = &(struct clk_init_data)
- {
- .name = "xo",
- .parent_names = (const char *[]) { "xo_board" },
- .num_parents = 1,
- .ops = &clk_fixed_factor_ops,
- },
-};
-
static struct clk_alpha_pll gpll0_early = {
- .offset = 0x0,
+ .offset = 0,
.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
.clkr = {
.enable_reg = 0x1480,
.enable_mask = BIT(0),
- .hw.init = &(struct clk_init_data)
- {
+ .hw.init = &(struct clk_init_data){
.name = "gpll0_early",
- .parent_names = (const char *[]) { "xo" },
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "xo",
+ .name = "xo_board",
+ },
.num_parents = 1,
.ops = &clk_alpha_pll_ops,
},
@@ -79,10 +47,9 @@ static struct clk_alpha_pll gpll0_early = {
};
static struct clk_alpha_pll_postdiv gpll0 = {
- .offset = 0x0,
+ .offset = 0,
.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
- .clkr.hw.init = &(struct clk_init_data)
- {
+ .clkr.hw.init = &(struct clk_init_data){
.name = "gpll0",
.parent_names = (const char *[]) { "gpll0_early" },
.num_parents = 1,
@@ -96,10 +63,12 @@ static struct clk_alpha_pll gpll4_early = {
.clkr = {
.enable_reg = 0x1480,
.enable_mask = BIT(4),
- .hw.init = &(struct clk_init_data)
- {
+ .hw.init = &(struct clk_init_data){
.name = "gpll4_early",
- .parent_names = (const char *[]) { "xo" },
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "xo",
+ .name = "xo_board",
+ },
.num_parents = 1,
.ops = &clk_alpha_pll_ops,
},
@@ -109,8 +78,7 @@ static struct clk_alpha_pll gpll4_early = {
static struct clk_alpha_pll_postdiv gpll4 = {
.offset = 0x1dc0,
.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
- .clkr.hw.init = &(struct clk_init_data)
- {
+ .clkr.hw.init = &(struct clk_init_data){
.name = "gpll4",
.parent_names = (const char *[]) { "gpll4_early" },
.num_parents = 1,
@@ -118,6 +86,28 @@ static struct clk_alpha_pll_postdiv gpll4 = {
},
};
+static const struct parent_map gcc_xo_gpll0_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+};
+
+static const struct clk_parent_data gcc_xo_gpll0[] = {
+ { .fw_name = "xo", .name = "xo_board", },
+ { .hw = &gpll0.clkr.hw },
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll4_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL4, 5 },
+};
+
+static const struct clk_parent_data gcc_xo_gpll0_gpll4[] = {
+ { .fw_name = "xo", .name = "xo_board", },
+ { .hw = &gpll0.clkr.hw },
+ { .hw = &gpll4.clkr.hw },
+};
+
static struct freq_tbl ftbl_ufs_axi_clk_src[] = {
F(5000, P_GPLL0, 12, 0, 0),
F(1, P_GPLL0, 6, 0, 0),
@@ -134,10 +124,9 @@ static struct clk_rcg2 ufs_axi_clk_src = {
.hid_width = 5,
.parent_map = gcc_xo_gpll0_map,
.freq_tbl = ftbl_ufs_axi_clk_src,
- .clkr.hw.init = &(struct clk_init_data)
- {
+ .clkr.hw.init = &(struct clk_init_data){
.name = "ufs_axi_clk_src",
- .parent_names = gcc_xo_gpll0,
+ .parent_data = gcc_xo_gpll0,
.num_parents = 2,
.ops = &clk_rcg2_ops,
},
@@ -155,10 +144,9 @@ static struct clk_rcg2 usb30_master_clk_src = {
[PATCH 3/9] clk: qcom: gcc-msm8994: Fix up SPI QUP clocks
Fix up SPI QUP freq tables to account for the fact
that not every QUP can run at the same set of frequencies.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/gcc-msm8994.c | 118 +
1 file changed, 105 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8994.c b/drivers/clk/qcom/gcc-msm8994.c
index 69241651b171..0ebc827f0f05 100644
--- a/drivers/clk/qcom/gcc-msm8994.c
+++ b/drivers/clk/qcom/gcc-msm8994.c
@@ -171,7 +171,7 @@ static struct clk_rcg2 blsp1_qup1_i2c_apps_clk_src = {
},
};
-static struct freq_tbl ftbl_blspqup_spi_apps_clk_src[] = {
+static struct freq_tbl ftbl_blsp1_qup1_spi_apps_clk_src[] = {
F(96, P_XO, 10, 1, 2),
F(480, P_XO, 4, 0, 0),
F(960, P_XO, 2, 0, 0),
@@ -189,7 +189,7 @@ static struct clk_rcg2 blsp1_qup1_spi_apps_clk_src = {
.mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll0_map,
- .freq_tbl = ftbl_blspqup_spi_apps_clk_src,
+ .freq_tbl = ftbl_blsp1_qup1_spi_apps_clk_src,
.clkr.hw.init = &(struct clk_init_data){
.name = "blsp1_qup1_spi_apps_clk_src",
.parent_data = gcc_xo_gpll0,
@@ -211,12 +211,25 @@ static struct clk_rcg2 blsp1_qup2_i2c_apps_clk_src = {
},
};
+static struct freq_tbl ftbl_blsp1_qup2_spi_apps_clk_src[] = {
+ F(96, P_XO, 10, 1, 2),
+ F(480, P_XO, 4, 0, 0),
+ F(960, P_XO, 2, 0, 0),
+ F(1500, P_GPLL0, 10, 1, 4),
+ F(1920, P_XO, 1, 0, 0),
+ F(2400, P_GPLL0, 12.5, 1, 2),
+ F(2500, P_GPLL0, 12, 1, 2),
+ F(4286, P_GPLL0, 14, 0, 0),
+ F(4615, P_GPLL0, 13, 0, 0),
+ { }
+};
+
static struct clk_rcg2 blsp1_qup2_spi_apps_clk_src = {
.cmd_rcgr = 0x06cc,
.mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll0_map,
- .freq_tbl = ftbl_blspqup_spi_apps_clk_src,
+ .freq_tbl = ftbl_blsp1_qup2_spi_apps_clk_src,
.clkr.hw.init = &(struct clk_init_data){
.name = "blsp1_qup2_spi_apps_clk_src",
.parent_data = gcc_xo_gpll0,
@@ -238,12 +251,25 @@ static struct clk_rcg2 blsp1_qup3_i2c_apps_clk_src = {
},
};
+static struct freq_tbl ftbl_blsp1_qup3_4_spi_apps_clk_src[] = {
+ F(96, P_XO, 10, 1, 2),
+ F(480, P_XO, 4, 0, 0),
+ F(960, P_XO, 2, 0, 0),
+ F(1500, P_GPLL0, 10, 1, 4),
+ F(1920, P_XO, 1, 0, 0),
+ F(2400, P_GPLL0, 12.5, 1, 2),
+ F(2500, P_GPLL0, 12, 1, 2),
+ F(4286, P_GPLL0, 14, 0, 0),
+ F(, P_GPLL0, 13.5, 0, 0),
+ { }
+};
+
static struct clk_rcg2 blsp1_qup3_spi_apps_clk_src = {
.cmd_rcgr = 0x074c,
.mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll0_map,
- .freq_tbl = ftbl_blspqup_spi_apps_clk_src,
+ .freq_tbl = ftbl_blsp1_qup3_4_spi_apps_clk_src,
.clkr.hw.init = &(struct clk_init_data){
.name = "blsp1_qup3_spi_apps_clk_src",
.parent_data = gcc_xo_gpll0,
@@ -270,7 +296,7 @@ static struct clk_rcg2 blsp1_qup4_spi_apps_clk_src = {
.mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll0_map,
- .freq_tbl = ftbl_blspqup_spi_apps_clk_src,
+ .freq_tbl = ftbl_blsp1_qup3_4_spi_apps_clk_src,
.clkr.hw.init = &(struct clk_init_data){
.name = "blsp1_qup4_spi_apps_clk_src",
.parent_data = gcc_xo_gpll0,
@@ -292,12 +318,25 @@ static struct clk_rcg2 blsp1_qup5_i2c_apps_clk_src = {
},
};
+static struct freq_tbl ftbl_blsp1_qup5_spi_apps_clk_src[] = {
+ F(96, P_XO, 10, 1, 2),
+ F(480, P_XO, 4, 0, 0),
+ F(960, P_XO, 2, 0, 0),
+ F(1500, P_GPLL0, 10, 1, 4),
+ F(1920, P_XO, 1, 0, 0),
+ F(2400, P_GPLL0, 12.5, 1, 2),
+ F(2500, P_GPLL0, 12, 1, 2),
+ F(4000, P_GPLL0, 15, 0, 0),
+ F(4286, P_GPLL0, 14, 0, 0),
+ { }
+};
+
static struct clk_rcg2 blsp1_qup5_spi_apps_clk_src = {
.cmd_rcgr = 0x084c,
.mnd_width = 8,
.hid_width = 5,
.parent_map = gcc_xo_gpll0_map,
- .freq_tbl = ftbl_blspqup_spi_apps_clk_src,
+ .freq_tbl = ftbl_blsp1_qup5_spi_apps_clk_src,
.clkr.hw.init = &(struct clk_init_data){
.name = "blsp1_qup5_spi_apps_clk_src",
.parent_data = gcc_xo_gpll0,
@@ -319,12 +358,25 @@ static struct clk_rcg2 blsp1_qup6_i2c_apps_clk_src = {
},
};
+static struct freq_tbl ftbl_blsp1_qup6_spi_apps_clk_src[] = {
+ F(96, P_XO, 10, 1, 2),
+ F(480, P_XO, 4, 0, 0),
+ F(960, P_XO, 2, 0, 0),
+ F(1500, P_GPLL0, 10, 1, 4),
+ F(1920, P_XO, 1, 0, 0),
+ F(2400, P_GPLL0, 12.5, 1, 2),
+ F(27906976, P_GPLL0, 1, 2, 43),
+ F(4138, P_GPLL0, 15, 0, 0),
+ F(4286, P_GPLL0, 14, 0, 0),
+ { }
+};
+
static struct clk_rcg2 bl
[PATCH 1/9] dt-bindings: clk: qcom: Add bindings for MSM8994 GCC driver
Add documentation for the MSM8994 GCC driver.
Signed-off-by: Konrad Dybcio
---
.../bindings/clock/qcom,gcc-msm8994.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
new file mode 100644
index ..f8067fb1bbd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8994.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/clock/qcom,gcc-msm8994.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Qualcomm Global Clock & Reset Controller Binding for MSM8994
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on MSM8994 and MSM8992.
+
+ See also:
+ - dt-bindings/clock/qcom,gcc-msm8994.h
+
+maintainers:
+ - Stephen Boyd
+ - Taniya Das
+
+properties:
+ compatible:
+enum:
+ - qcom,gcc-msm8992
+ - qcom,gcc-msm8994
+
+ clocks:
+items:
+ - description: XO source
+ - description: Sleep clock source
+
+ clock-names:
+items:
+ - const: xo
+ - const: sleep
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+ reg:
+maxItems: 1
+
+ protected-clocks:
+description:
+ Protected clock specifier list as per common clock binding.
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+clock-controller@30 {
+ compatible = "qcom,gcc-msm8994";
+ reg = <0x30 0x9>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ clocks = <&xo_board>, <&sleep_clk>;
+ clock-names = "xo", "sleep";
+};
+...
--
2.30.2
Re: [PATCH 0/4] Expose and manage PCI device reset
On Sat, Mar 13, 2021 at 12:10:38AM +0530, Amey Narkhede wrote: > On 21/03/12 11:20AM, Alex Williamson wrote: > > On Fri, 12 Mar 2021 23:04:48 +0530 > > ameynarkhed...@gmail.com wrote: > > > > > From: Amey Narkhede > > > > > > PCI and PCIe devices may support a number of possible reset mechanisms > > > for example Function Level Reset (FLR) provided via Advanced Feature or > > > PCIe capabilities, Power Management reset, bus reset, or device specific > > > reset. > > > Currently the PCI subsystem creates a policy prioritizing these reset > > > methods > > > which provides neither visibility nor control to userspace. > > > > > > Expose the reset methods available per device to userspace, via sysfs > > > and allow an administrative user or device owner to have ability to > > > manage per device reset method priorities or exclusions. > > > This feature aims to allow greater control of a device for use cases > > > as device assignment, where specific device or platform issues may > > > interact poorly with a given reset method, and for which device specific > > > quirks have not been developed. > > > > > > Suggested-by: Alex Williamson > > > Reviewed-by: Alex Williamson > > > Reviewed-by: Raphael Norwitz > > > > Reviews/Acks/Sign-off-by from others (aside from Tested/Reported-by) > > really need to be explicit, IMO. This is a common issue for new > > developers, but it really needs to be more formal. I wouldn't claim to > > be able to speak for Raphael and interpret his comments so far as his > > final seal of approval. > > > > Also in the patches, all Sign-offs/Reviews/Acks need to be above the > > triple dash '---' line. Anything between that line and the beginning > > of the diff is discarded by tools. People will often use that for > > difference between version since it will be discarded on commit. > > Likewise, the cover letter is not committed, so Review-by there are > > generally not done. I generally make my Sign-off last in the chain and > > maintainers will generally add theirs after that. This makes for a > > chain where someone can read up from the bottom to see how this commit > > entered the kernel. Reviews, Acks, and whatnot will therefore usually > > be collected above the author posting the patch. > > > > Since this is a v1 patch and it's likely there will be more revisions, > > rather than send a v2 immediately with corrections, I'd probably just > > reply to the cover letter retracting Raphael's Review-by for him to > > send his own and noting that you'll fix the commit reviews formatting, > > but will wait for a bit for further comments before sending a new > > version. > > > > No big deal, nice work getting it sent out. Thanks, > > > > Alex > > > Raphael sent me the email with > Reviewed-by: Raphael Norwitz that > is why I included it. > So basically in v2 I should reorder tags such that Sign-off will be > the last. Did I get that right? Or am I missing something? > Just to confirm, I did send Reviewed-by: Raphael Norwitz for the latest version and I'm happy to have it on this series. > Thanks, > Amey > > > > Amey Narkhede (4): > > > PCI: Refactor pcie_flr to follow calling convention of other reset > > > methods > > > PCI: Add new bitmap for keeping track of supported reset mechanisms > > > PCI: Remove reset_fn field from pci_dev > > > PCI/sysfs: Allow userspace to query and set device reset mechanism > > > > > > Documentation/ABI/testing/sysfs-bus-pci | 15 ++ > > > drivers/crypto/cavium/nitrox/nitrox_main.c| 4 +- > > > drivers/crypto/qat/qat_common/adf_aer.c | 2 +- > > > drivers/infiniband/hw/hfi1/chip.c | 4 +- > > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- > > > .../ethernet/cavium/liquidio/lio_vf_main.c| 4 +- > > > .../ethernet/cavium/liquidio/octeon_mailbox.c | 2 +- > > > drivers/net/ethernet/freescale/enetc/enetc.c | 2 +- > > > .../ethernet/freescale/enetc/enetc_pci_mdio.c | 2 +- > > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 +- > > > drivers/pci/pci-sysfs.c | 68 +++- > > > drivers/pci/pci.c | 160 ++ > > > drivers/pci/pci.h | 11 +- > > > drivers/pci/pcie/aer.c| 12 +- > > > drivers/pci/probe.c | 4 +- > > > drivers/pci/quirks.c | 17 +- > > > include/linux/pci.h | 17 +- > > > 17 files changed, 213 insertions(+), 117 deletions(-) > > > > > > -- > > > 2.30.2 > > > > >
[PATCH v4] perf annotate: Fix sample events lost in stdio mode
In hist__find_annotations function, since different hist_entry may point to same
symbol, we free notes->src to signal already processed this symbol in stdio
mode;
when annotate, entry will skipped if notes->src is NULL to avoid repeated
output.
However, there is a problem, for example, run the following command:
# perf record -e branch-misses -e branch-instructions -a sleep 1
perf.data file contains different types of sample event.
If the same IP sample event exists in branch-misses and branch-instructions,
this event uses the same symbol. When annotate branch-misses events, notes->src
corresponding to this event is set to null, as a result, when annotate
branch-instructions events, this event is skipped and no annotate is output.
Solution of this patch is to remove zfree in hists__find_annotations and
change sort order to "dso,symbol" to avoid duplicate output when different
processes correspond to the same symbol.
---
tools/perf/builtin-annotate.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index a23ba6bb99b6..ad169e3e2e8f 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct hists *hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
- /*
-* Since we have a hist_entry per IP for the same
-* symbol, free he->ms.sym->src to signal we already
-* processed this symbol.
-*/
- zfree(¬es->src->cycles_hist);
- zfree(¬es->src);
}
}
}
@@ -624,6 +617,12 @@ int cmd_annotate(int argc, const char **argv)
if (setup_sorting(annotate.session->evlist) < 0)
usage_with_options(annotate_usage, options);
} else {
+ /*
+* Events of different processes may correspond to the same
+* symbol, we do not care about the processes in annotate,
+* set sort order to avoid repeated output.
+*/
+ sort_order = "dso,symbol";
if (setup_sorting(NULL) < 0)
usage_with_options(annotate_usage, options);
}
--
2.30.GIT
[linux-stable-rc CI] Test report for 5.4.106-rc1 /arm64
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-5.4.y Arch: arm64 Version: 5.4.106-rc1 Commit: e8e77f614b2e2ba579aa4ff7c507026bd86dac64 Compiler: gcc version 7.3.0 (GCC) All testcases PASSED. Testcase Result Summary: total_num: 4693 succeed_num: 4693 failed_num: 0 timeout_num: 0 Tested-by: Hulk Robot
[PATCH 1/2] dt-bindings: clock: Add MDM9607 GCC clock bindings
Add device tree bindings for global clock controller on MDM9607 SoC. Signed-off-by: Konrad Dybcio --- .../devicetree/bindings/clock/qcom,gcc.yaml | 2 + include/dt-bindings/clock/qcom,gcc-mdm9607.h | 104 ++ 2 files changed, 106 insertions(+) create mode 100644 include/dt-bindings/clock/qcom,gcc-mdm9607.h diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index ee0467fb5e31..5f7ea48d7c52 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -29,6 +29,7 @@ description: | - dt-bindings/clock/qcom,gcc-msm8974.h - dt-bindings/reset/qcom,gcc-msm8974.h - dt-bindings/clock/qcom,gcc-msm8994.h + - dt-bindings/clock/qcom,gcc-mdm9607.h - dt-bindings/clock/qcom,gcc-mdm9615.h - dt-bindings/reset/qcom,gcc-mdm9615.h - dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660) @@ -41,6 +42,7 @@ properties: - qcom,gcc-ipq4019 - qcom,gcc-ipq6018 - qcom,gcc-ipq8064 + - qcom,gcc-mdm9607 - qcom,gcc-msm8660 - qcom,gcc-msm8916 - qcom,gcc-msm8939 diff --git a/include/dt-bindings/clock/qcom,gcc-mdm9607.h b/include/dt-bindings/clock/qcom,gcc-mdm9607.h new file mode 100644 index ..357a680a40da --- /dev/null +++ b/include/dt-bindings/clock/qcom,gcc-mdm9607.h @@ -0,0 +1,104 @@ +/* SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) */ +/* + * Copyright (c) 2021, Konrad Dybcio + */ + +#ifndef _DT_BINDINGS_CLK_MSM_GCC_9607_H +#define _DT_BINDINGS_CLK_MSM_GCC_9607_H + +#define GPLL0 0 +#define GPLL0_EARLY1 +#define GPLL1 2 +#define GPLL1_VOTE 3 +#define GPLL2 4 +#define GPLL2_EARLY5 +#define PCNOC_BFDCD_CLK_SRC6 +#define SYSTEM_NOC_BFDCD_CLK_SRC 7 +#define GCC_SMMU_CFG_CLK 8 +#define APSS_AHB_CLK_SRC 9 +#define GCC_QDSS_DAP_CLK 10 +#define BLSP1_QUP1_I2C_APPS_CLK_SRC11 +#define BLSP1_QUP1_SPI_APPS_CLK_SRC12 +#define BLSP1_QUP2_I2C_APPS_CLK_SRC13 +#define BLSP1_QUP2_SPI_APPS_CLK_SRC14 +#define BLSP1_QUP3_I2C_APPS_CLK_SRC15 +#define BLSP1_QUP3_SPI_APPS_CLK_SRC16 +#define BLSP1_QUP4_I2C_APPS_CLK_SRC17 +#define BLSP1_QUP4_SPI_APPS_CLK_SRC18 +#define BLSP1_QUP5_I2C_APPS_CLK_SRC19 +#define BLSP1_QUP5_SPI_APPS_CLK_SRC20 +#define BLSP1_QUP6_I2C_APPS_CLK_SRC21 +#define BLSP1_QUP6_SPI_APPS_CLK_SRC22 +#define BLSP1_UART1_APPS_CLK_SRC 23 +#define BLSP1_UART2_APPS_CLK_SRC 24 +#define CRYPTO_CLK_SRC 25 +#define GP1_CLK_SRC26 +#define GP2_CLK_SRC27 +#define GP3_CLK_SRC28 +#define PDM2_CLK_SRC 29 +#define SDCC1_APPS_CLK_SRC 30 +#define SDCC2_APPS_CLK_SRC 31 +#define APSS_TCU_CLK_SRC 32 +#define USB_HS_SYSTEM_CLK_SRC 33 +#define GCC_BLSP1_AHB_CLK 34 +#define GCC_BLSP1_SLEEP_CLK35 +#define GCC_BLSP1_QUP1_I2C_APPS_CLK36 +#define GCC_BLSP1_QUP1_SPI_APPS_CLK37 +#define GCC_BLSP1_QUP2_I2C_APPS_CLK38 +#define GCC_BLSP1_QUP2_SPI_APPS_CLK39 +#define GCC_BLSP1_QUP3_I2C_APPS_CLK40 +#define GCC_BLSP1_QUP3_SPI_APPS_CLK41 +#define GCC_BLSP1_QUP4_I2C_APPS_CLK42 +#define GCC_BLSP1_QUP4_SPI_APPS_CLK43 +#define GCC_BLSP1_QUP5_I2C_APPS_CLK44 +#define GCC_BLSP1_QUP5_SPI_APPS_CLK45 +#define GCC_BLSP1_QUP6_I2C_APPS_CLK46 +#define GCC_BLSP1_QUP6_SPI_APPS_CLK47 +#define GCC_BLSP1_UART1_APPS_CLK 48 +#define GCC_BLSP1_UART2_APPS_CLK 49 +#define GCC_BOOT_ROM_AHB_CLK 50 +#define GCC_CRYPTO_AHB_CLK 51 +#define GCC_CRYPTO_AXI_CLK 52 +#define GCC_CRYPTO_CLK 53 +#define GCC_GP1_CLK54 +#define GCC_GP2_CLK55 +#define GCC_GP3_CLK56 +#define GCC_MSS_CFG_AHB_CLK57 +#define GCC_PDM2_CLK 58 +#define GCC_PDM_AHB_CLK
[PATCH 2/2] clk: qcom: Add MDM9607 GCC driver
Add Global Clock Controller (GCC) support for MDM9607 SoC.
Signed-off-by: Konrad Dybcio
---
drivers/clk/qcom/Kconfig |7 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-mdm9607.c | 1656
3 files changed, 1664 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-mdm9607.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 45646b867cdb..c84b2c896a27 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -210,6 +210,13 @@ config MSM_LCC_8960
Say Y if you want to use audio devices such as i2s, pcm,
SLIMBus, etc.
+config MDM_GCC_9607
+ tristate "MDM9607 Global Clock Controller"
+ help
+ Support for the global clock controller on mdm9607 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ I2C, USB, SD/eMMC, etc.
+
config MDM_GCC_9615
tristate "MDM9615 Global Clock Controller"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index c8291312e723..9495bf6a18d0 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IPQ_GCC_6018) += gcc-ipq6018.o
obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
obj-$(CONFIG_IPQ_GCC_8074) += gcc-ipq8074.o
obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
+obj-$(CONFIG_MDM_GCC_9607) += gcc-mdm9607.o
obj-$(CONFIG_MDM_GCC_9615) += gcc-mdm9615.o
obj-$(CONFIG_MDM_LCC_9615) += lcc-mdm9615.o
obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
diff --git a/drivers/clk/qcom/gcc-mdm9607.c b/drivers/clk/qcom/gcc-mdm9607.c
new file mode 100644
index ..a4b3cff7e98f
--- /dev/null
+++ b/drivers/clk/qcom/gcc-mdm9607.c
@@ -0,0 +1,1656 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2021, Konrad Dybcio
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-alpha-pll.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+#include "gdsc.h"
+
+enum {
+ P_XO,
+ P_BIMC,
+ P_GPLL0,
+ P_GPLL1,
+ P_GPLL2,
+ P_SLEEP_CLK,
+};
+
+static const struct parent_map gcc_xo_sleep_map[] = {
+ { P_XO, 0 },
+ { P_SLEEP_CLK, 6 }
+};
+
+static const struct clk_parent_data gcc_xo_sleep[] = {
+ { .fw_name = "xo" },
+ { .fw_name = "sleep_clk" },
+};
+
+static struct clk_alpha_pll gpll0_early = {
+ .offset = 0x21000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .clkr = {
+ .enable_reg = 0x45000,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data)
+ {
+ .name = "gpll0_early",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_ops,
+ },
+ },
+};
+
+static struct clk_alpha_pll_postdiv gpll0 = {
+ .offset = 0x21000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .clkr.hw.init = &(struct clk_init_data)
+ {
+ .name = "gpll0",
+ .parent_hws = (const struct clk_hw *[]){ &gpll0_early.clkr.hw },
+ .num_parents = 1,
+ .ops = &clk_alpha_pll_postdiv_ops,
+ },
+};
+
+static const struct parent_map gcc_xo_gpll0_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+};
+
+static const struct clk_parent_data gcc_xo_gpll0[] = {
+ { .fw_name = "xo" },
+ { .hw = &gpll0.clkr.hw },
+};
+
+static struct clk_pll gpll1 = {
+ .l_reg = 0x20004,
+ .m_reg = 0x20008,
+ .n_reg = 0x2000c,
+ .config_reg = 0x20010,
+ .mode_reg = 0x2,
+ .status_reg = 0x2001c,
+ .status_bit = 17,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpll1",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "xo",
+ },
+ .num_parents = 1,
+ .ops = &clk_pll_ops,
+ },
+};
+
+static struct clk_regmap gpll1_vote = {
+ .enable_reg = 0x45000,
+ .enable_mask = BIT(1),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpll1_vote",
+ .parent_hws = (const struct clk_hw *[]){ &gpll1.clkr.hw },
+ .num_parents = 1,
+ .ops = &clk_pll_vote_ops,
+ },
+};
+
+static const struct parent_map gcc_xo_gpll0_gpll1_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 1 },
+ { P_GPLL1, 2 },
+};
+
+static const struct clk_parent_data gcc_xo_gpll0_gpll1[] = {
+ { .fw_name = "xo" },
+ { .hw = &gpll0.clkr.hw },
+ { .hw = &gpll1_vote.hw },
+};
+
+
+static const struct parent_map gcc_xo_gpll0_gpll1_sl
Re: [PATCH] perf annotate: Fix sample events lost in stdio mode
Hello, Namhyung
On 2021/3/12 18:20, Yang Jihong wrote:
Hello,
On 2021/3/12 16:39, Namhyung Kim wrote:
On Fri, Mar 12, 2021 at 4:19 PM Yang Jihong
wrote:
Hello,
On 2021/3/12 13:49, Namhyung Kim wrote:
Hi,
On Fri, Mar 12, 2021 at 12:24 PM Yang Jihong
wrote:
Hello, Namhyung
On 2021/3/11 22:42, Namhyung Kim wrote:
Hi,
On Thu, Mar 11, 2021 at 5:48 PM Yang Jihong
wrote:
Hello,
On 2021/3/6 16:28, Yang Jihong wrote:
In hist__find_annotations function, since have a hist_entry per
IP for the same
symbol, we free notes->src to signal already processed this
symbol in stdio mode;
when annotate, entry will skipped if notes->src is NULL to avoid
repeated output.
I'm not sure it's still true that we have a hist_entry per IP.
Afaik the default sort key is comm,dso,sym which means it should
have a single
hist_entry for each symbol. It seems like an old comment..
Emm, yes, we have a hist_entry for per IP.
a member named "sym" in struct "hist_entry" points to symbol,
different IP may point to the same symbol.
Are you sure about this? It seems like a bug then.
Yes, now each IP corresponds to a hist_entry :)
Last week I found that some sample events were missing when perf
annotate in stdio mode, so I went through the annotate code carefully.
The event handling process is as follows:
process_sample_event
evsel_add_sample
hists__add_entry
__hists__add_entry
hists__findnew_entry
hist_entry__new -> here allock new
hist_entry
Yeah, so this is for a symbol.
hist_entry__inc_addr_samples
symbol__inc_addr_samples
symbol__hists
annotated_source__new -> here alloc annotate
soruce
annotated_source__alloc_histograms -> here alloc histograms
This should be for each IP (ideally it should be per instruction).
By bugs, do you mean there's something wrong?
No. I think we were saying about different things. :)
OK, :)
diff --git a/tools/perf/builtin-annotate.c
b/tools/perf/builtin-annotate.c
index a23ba6bb99b6..a91fe45bd69f 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct
hists *hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
- /*
- * Since we have a hist_entry per IP for
the same
- * symbol, free he->ms.sym->src to signal
we already
- * processed this symbol.
- */
- zfree(¬es->src->cycles_hist);
- zfree(¬es->src);
}
}
}
This solution may have the following problem:
For example, if two sample events are in two different processes
but in
the same symbol, repeated output may occur.
Therefore, a flag is required to indicate whether the symbol has been
processed to avoid repeated output.
Hmm.. ok. Yeah we don't care about the processes here.
Then we should remove it from the sort key like below:
@@ -624,6 +617,7 @@ int cmd_annotate(int argc, const char **argv)
if (setup_sorting(annotate.session->evlist) < 0)
usage_with_options(annotate_usage, options);
} else {
+ sort_order = "dso,symbol";
if (setup_sorting(NULL) < 0)
usage_with_options(annotate_usage, options);
}
Are you referring to this solution?
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct hists
*hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
- /*
- * Since we have a hist_entry per IP for the
same
- * symbol, free he->ms.sym->src to signal we
already
- * processed this symbol.
- */
- zfree(¬es->src->cycles_hist);
- zfree(¬es->src);
}
}
}
@@ -624,6 +617,7 @@ int cmd_annotate(int argc, const char **argv)
if (setup_sorting(annotate.session->evlist) < 0)
usage_with_options(annotate_usage, options);
} else {
+ sort_order = "dso,symbol";
if (setup_sorting(NULL) < 0)
usage_with_options(annotate_usage, options);
}
It seems to be a better solution without adding new member.
I just tested it and it works.
If we decide to use this solution, I'll resubmit a v3 patch.
I prefer changing the sort order (and removing the zfree and comments).
OK, I'll submit a v3 patch based on the "changing the sort order" solution.
I have
[PATCH] ACPI: fix various typos in comments
Fix trivial ACPI driver comment typos.
s/notifcations/notifications/
s/Ajust/Adjust/
s/preform/perform/
s/atrributes/attributes/
s/Souce/Source/
s/Evalutes/Evaluates/
s/Evalutes/Evaluates/
s/specifiy/specify/
s/promixity/proximity/
s/presuambly/presumably/
s/Evalute/Evaluate/
s/specificed/specified/
s/rountine/routine/
s/previosuly/previously/
Change comment referencing pcc_send_cmd to send_pcc_cmd.
Cc: triv...@kernel.org
Signed-off-by: Tom Saeger
---
drivers/acpi/ac.c | 2 +-
drivers/acpi/acpi_video.c | 4 ++--
drivers/acpi/apei/erst.c | 2 +-
drivers/acpi/apei/hest.c | 2 +-
drivers/acpi/cppc_acpi.c | 10 +-
drivers/acpi/numa/hmat.c | 2 +-
drivers/acpi/pmic/intel_pmic_chtcrc.c | 2 +-
drivers/acpi/power.c | 2 +-
drivers/acpi/processor_perflib.c | 2 +-
drivers/acpi/resource.c | 2 +-
drivers/acpi/scan.c | 2 +-
11 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index b41180330cc1..b86ee6e3baa7 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -187,7 +187,7 @@ static int acpi_ac_battery_notify(struct notifier_block *nb,
/*
* On HP Pavilion dv6-6179er AC status notifications aren't triggered
* when adapter is plugged/unplugged. However, battery status
-* notifcations are triggered when battery starts charging or
+* notifications are triggered when battery starts charging or
* discharging. Re-reading AC status triggers lost AC notifications,
* if AC status has changed.
*/
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 2ea1781290cc..698c67f06e90 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -1392,7 +1392,7 @@ acpi_video_get_next_level(struct acpi_video_device
*device,
break;
}
}
- /* Ajust level_current to closest available level */
+ /* Adjust level_current to closest available level */
level_current += delta;
for (i = ACPI_VIDEO_FIRST_LEVEL; i < device->brightness->count; i++) {
l = device->brightness->levels[i];
@@ -1555,7 +1555,7 @@ acpi_video_bus_get_devices(struct acpi_video_bus *video,
/*
* Win8 requires setting bit2 of _DOS to let firmware know it shouldn't
- * preform any automatic brightness change on receiving a notification.
+ * perform any automatic brightness change on receiving a notification.
*/
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index b9597216d021..242f3c2d5533 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -54,7 +54,7 @@ EXPORT_SYMBOL_GPL(erst_disable);
static struct acpi_table_erst *erst_tab;
-/* ERST Error Log Address Range atrributes */
+/* ERST Error Log Address Range attributes */
#define ERST_RANGE_RESERVED0x0001
#define ERST_RANGE_NVRAM 0x0002
#define ERST_RANGE_SLOW0x0004
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index f220bb00e91b..277f00b288d1 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * APEI Hardware Error Souce Table support
+ * APEI Hardware Error Source Table support
*
* HEST describes error sources in detail; communicates operational
* parameters (i.e. severity levels, masking bits, and threshold
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 69057fcd2c04..12478e62d8d1 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -101,14 +101,14 @@ static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
(cpc)->cpc_entry.reg.space_id ==\
ACPI_ADR_SPACE_PLATFORM_COMM)
-/* Evalutes to True if reg is a NULL register descriptor */
+/* Evaluates to True if reg is a NULL register descriptor */
#define IS_NULL_REG(reg) ((reg)->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY && \
(reg)->address == 0 && \
(reg)->bit_width == 0 &&\
(reg)->bit_offset == 0 && \
(reg)->access_width == 0)
-/* Evalutes to True if an optional cpc field is supported */
+/* Evaluates to True if an optional cpc field is supported */
#define CPC_SUPPORTED(cpc) ((cpc)->type == ACPI_TYPE_INTEGER ? \
!!(cpc)->cpc_entry.int_value : \
!IS_NULL_REG(&(cpc)->cpc_entry.reg))
@@ -1330,7 +1330,7 @@ int cppc_set_perf(int cpu, struct cppc_perf_ctrls
*perf_ctrls)
* is still with OSPM.
* pending_pcc_write_cmd can also be cleared
