[PATCH] octeontx2-af: debugfs: Remove unneeded semicolon
fix semicolon.cocci warnings:
drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c:1788:3-4: Unneeded
semicolon
drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c:1809:3-4: Unneeded
semicolon
Signed-off-by: Xu Wang
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
index d27543c1a166..b5b5032a1aa2 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
@@ -1785,7 +1785,7 @@ static void rvu_dbg_npc_mcam_show_action(struct seq_file
*s,
break;
default:
break;
- };
+ }
} else {
switch (rule->rx_action.op) {
case NIX_RX_ACTIONOP_DROP:
@@ -1806,7 +1806,7 @@ static void rvu_dbg_npc_mcam_show_action(struct seq_file
*s,
break;
default:
break;
- };
+ }
}
}
--
2.17.1
Re: [PATCH] can: mcp251xfd: mcp251xfd_handle_ivmif(): fix wrong NULL pointer check
On 1/19/21 3:02 AM, angkery wrote: > From: Junlin Yang > > if alloc_can_err_skb() returns NULL, we should check skb instead of cf. Have a look at the function, there is a check for cf several times before this. But as cf is initialized as NULL this is should be no problem. While in: | ca4c6ebeeb50 can: mcp251xfd: mcp251xfd_handle_rxif_one(): | fix wrong NULL pointer check a real problem has been fixed. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: OpenPGP digital signature
[PATCH V8 00/10] remoteproc: imx_rproc: support iMX8MQ/M
From: Peng Fan V8: Address sparse warning in patch 4/10 reported by kernel test robot V7: Add R-b tag from Mathieu vdevbuffer->vdev0buffer in patch 1/10, 7/10 correct err msg and shutdown seq per Mathieu's comments in patch 10/10 Hope this version is ok to be merged. V6: Add R-b tag from Mathieu Convert imx-rproc.txt to yaml and add dt-bindings support for i.MX8MQ/M, patch 1/10 2/10 No other changes. V5: Apply on Linux next Add V5 subject prefix Add R-b tag from Bjorn for 1/8, 2/8, 3/8 https://patchwork.kernel.org/project/linux-remoteproc/cover/20201229033019.25899-1-peng@nxp.com/ V4: According to Bjorn's comments, add is_iomem for da to va usage 1/8, 2/8 is new patch 3/8, follow Bjorn's comments to correct/update the err msg. 6/8, new patch 8/8, use dev_err_probe to simplify code, use queue_work instead schedule_delayed_work V3: Since I was quite busy in the past days, V3 is late Rebased on Linux-next Add R-b tags 1/7: Add R-b tag of Mathieu, add comments 4/7: Typo fix 5/7: Add R-b tag of Mathieu, drop index Per Mathieu's comments 6/7: Add R-b tag of Mathieu 7/7: Add comment for vqid << 16, drop unneeded timeout settings of mailbox Use queue_work instead of schedule_delayed_work free mbox channels when remove https://lkml.org/lkml/2020/12/4/82 V2: Rebased on linux-next Dropped early boot feature to make patchset simple. Drop rsc-da https://patchwork.kernel.org/project/linux-remoteproc/cover/20200927064131.24101-1-peng@nxp.com/ V1: https://patchwork.kernel.org/cover/11682461/ This patchset is to support i.MX8MQ/M coproc. The early boot feature was dropped to make the patchset small in V2. Since i.MX specific TCM memory requirement, add elf platform hook. Several patches have got reviewed by Oleksij and Mathieu in v1. Peng Fan (10): dt-bindings: remoteproc: convert imx rproc bindings to json-schema dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M support remoteproc: introduce is_iomem to rproc_mem_entry remoteproc: add is_iomem to da_to_va remoteproc: imx_rproc: correct err message remoteproc: imx_rproc: use devm_ioremap remoteproc: imx_rproc: add i.MX specific parse fw hook remoteproc: imx_rproc: support i.MX8MQ/M remoteproc: imx_rproc: ignore mapping vdev regions remoteproc: imx_proc: enable virtio/mailbox .../bindings/remoteproc/fsl,imx-rproc.yaml| 108 .../bindings/remoteproc/imx-rproc.txt | 33 --- drivers/remoteproc/imx_rproc.c| 260 +- drivers/remoteproc/ingenic_rproc.c| 2 +- drivers/remoteproc/keystone_remoteproc.c | 2 +- drivers/remoteproc/mtk_scp.c | 6 +- drivers/remoteproc/omap_remoteproc.c | 2 +- drivers/remoteproc/pru_rproc.c| 2 +- drivers/remoteproc/qcom_q6v5_adsp.c | 2 +- drivers/remoteproc/qcom_q6v5_pas.c| 2 +- drivers/remoteproc/qcom_q6v5_wcss.c | 2 +- drivers/remoteproc/qcom_wcnss.c | 2 +- drivers/remoteproc/remoteproc_core.c | 7 +- drivers/remoteproc/remoteproc_coredump.c | 8 +- drivers/remoteproc/remoteproc_debugfs.c | 2 +- drivers/remoteproc/remoteproc_elf_loader.c| 21 +- drivers/remoteproc/remoteproc_internal.h | 2 +- drivers/remoteproc/st_slim_rproc.c| 2 +- drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +- drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +- drivers/remoteproc/wkup_m3_rproc.c| 2 +- include/linux/remoteproc.h| 4 +- 22 files changed, 407 insertions(+), 68 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml delete mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt -- 2.28.0
[PATCH V8 06/10] remoteproc: imx_rproc: use devm_ioremap
From: Peng Fan
We might need to map an region multiple times, becaue the region might
be shared between remote processors, such i.MX8QM with dual M4 cores.
So use devm_ioremap, not devm_ioremap_resource.
Reviewed-by: Oleksij Rempel
Reviewed-by: Richard Zhu
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
drivers/remoteproc/imx_rproc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 2a093cea4997..47fc1d06be6a 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -296,7 +296,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (b >= IMX7D_RPROC_MEM_MAX)
break;
- priv->mem[b].cpu_addr = devm_ioremap_resource(>dev, );
+ /* Not use resource version, because we might share region */
+ priv->mem[b].cpu_addr = devm_ioremap(>dev, res.start,
resource_size());
if (IS_ERR(priv->mem[b].cpu_addr)) {
dev_err(dev, "failed to remap %pr\n", );
err = PTR_ERR(priv->mem[b].cpu_addr);
--
2.28.0
[PATCH V8 03/10] remoteproc: introduce is_iomem to rproc_mem_entry
From: Peng Fan
Introduce is_iomem to indicate this piece memory is iomem or not.
Reviewed-by: Bjorn Andersson
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
include/linux/remoteproc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index f28ee75d1005..a5f6d2d9cde2 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -315,6 +315,7 @@ struct rproc;
/**
* struct rproc_mem_entry - memory entry descriptor
* @va:virtual address
+ * @is_iomem: io memory
* @dma: dma address
* @len: length, in bytes
* @da: device address
@@ -329,6 +330,7 @@ struct rproc;
*/
struct rproc_mem_entry {
void *va;
+ bool is_iomem;
dma_addr_t dma;
size_t len;
u32 da;
--
2.28.0
[PATCH V8 07/10] remoteproc: imx_rproc: add i.MX specific parse fw hook
From: Peng Fan
The hook is used to parse memory-regions and load resource table
from the address the remote processor published.
Reviewed-by: Richard Zhu
Reviewed-by: Mathieu Poirier
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 47fc1d06be6a..5ae1f5209548 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -241,10 +242,102 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64
da, size_t len, bool *i
return va;
}
+static int imx_rproc_mem_alloc(struct rproc *rproc,
+ struct rproc_mem_entry *mem)
+{
+ struct device *dev = rproc->dev.parent;
+ void *va;
+
+ dev_dbg(dev, "map memory: %p+%zx\n", >dma, mem->len);
+ va = ioremap_wc(mem->dma, mem->len);
+ if (IS_ERR_OR_NULL(va)) {
+ dev_err(dev, "Unable to map memory region: %p+%zx\n",
+ >dma, mem->len);
+ return -ENOMEM;
+ }
+
+ /* Update memory entry va */
+ mem->va = va;
+
+ return 0;
+}
+
+static int imx_rproc_mem_release(struct rproc *rproc,
+struct rproc_mem_entry *mem)
+{
+ dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", >dma);
+ iounmap(mem->va);
+
+ return 0;
+}
+
+static int imx_rproc_parse_memory_regions(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device_node *np = priv->dev->of_node;
+ struct of_phandle_iterator it;
+ struct rproc_mem_entry *mem;
+ struct reserved_mem *rmem;
+ u32 da;
+
+ /* Register associated reserved memory regions */
+ of_phandle_iterator_init(, np, "memory-region", NULL, 0);
+ while (of_phandle_iterator_next() == 0) {
+ /*
+* Ignore the first memory region which will be used vdev
buffer.
+* No need to do extra handlings, rproc_add_virtio_dev will
handle it.
+*/
+ if (!strcmp(it.node->name, "vdev0buffer"))
+ continue;
+
+ rmem = of_reserved_mem_lookup(it.node);
+ if (!rmem) {
+ dev_err(priv->dev, "unable to acquire memory-region\n");
+ return -EINVAL;
+ }
+
+ /* No need to translate pa to da, i.MX use same map */
+ da = rmem->base;
+
+ /* Register memory region */
+ mem = rproc_mem_entry_init(priv->dev, NULL,
(dma_addr_t)rmem->base, rmem->size, da,
+ imx_rproc_mem_alloc,
imx_rproc_mem_release,
+ it.node->name);
+
+ if (mem)
+ rproc_coredump_add_segment(rproc, da, rmem->size);
+ else
+ return -ENOMEM;
+
+ rproc_add_carveout(rproc, mem);
+ }
+
+ return 0;
+}
+
+static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+ int ret = imx_rproc_parse_memory_regions(rproc);
+
+ if (ret)
+ return ret;
+
+ ret = rproc_elf_load_rsc_table(rproc, fw);
+ if (ret)
+ dev_info(>dev, "No resource table in elf\n");
+
+ return 0;
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
.da_to_va = imx_rproc_da_to_va,
+ .load = rproc_elf_load_segments,
+ .parse_fw = imx_rproc_parse_fw,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+ .sanity_check = rproc_elf_sanity_check,
+ .get_boot_addr = rproc_elf_get_boot_addr,
};
static int imx_rproc_addr_init(struct imx_rproc *priv,
--
2.28.0
[PATCH V8 08/10] remoteproc: imx_rproc: support i.MX8MQ/M
From: Peng Fan
Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.
Reviewed-by: Richard Zhu
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
drivers/remoteproc/imx_rproc.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 5ae1f5209548..fa01e64cc791 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -88,6 +88,34 @@ struct imx_rproc {
struct clk *clk;
};
+static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCML - alias */
+ { 0x, 0x007e, 0x0002, 0 },
+ /* OCRAM_S */
+ { 0x0018, 0x0018, 0x8000, 0 },
+ /* OCRAM */
+ { 0x0090, 0x0090, 0x0002, 0 },
+ /* OCRAM */
+ { 0x0092, 0x0092, 0x0002, 0 },
+ /* QSPI Code - alias */
+ { 0x0800, 0x0800, 0x0800, 0 },
+ /* DDR (Code) - alias */
+ { 0x1000, 0x8000, 0x0FFE, 0 },
+ /* TCML */
+ { 0x1FFE, 0x007E, 0x0002, ATT_OWN },
+ /* TCMU */
+ { 0x2000, 0x0080, 0x0002, ATT_OWN },
+ /* OCRAM_S */
+ { 0x2018, 0x0018, 0x8000, ATT_OWN },
+ /* OCRAM */
+ { 0x2020, 0x0090, 0x0002, ATT_OWN },
+ /* OCRAM */
+ { 0x2022, 0x0092, 0x0002, ATT_OWN },
+ /* DDR (Data) */
+ { 0x4000, 0x4000, 0x8000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
/* dev addr , sys addr , size , flags */
/* OCRAM_S (M4 Boot code) - alias */
@@ -138,6 +166,15 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] =
{
{ 0x8000, 0x8000, 0x6000, 0 },
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
+ .src_reg= IMX7D_SRC_SCR,
+ .src_mask = IMX7D_M4_RST_MASK,
+ .src_start = IMX7D_M4_START,
+ .src_stop = IMX7D_M4_STOP,
+ .att= imx_rproc_att_imx8mq,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx8mq),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
.src_reg= IMX7D_SRC_SCR,
.src_mask = IMX7D_M4_RST_MASK,
@@ -496,6 +533,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx7d-cm4", .data = _rproc_cfg_imx7d },
{ .compatible = "fsl,imx6sx-cm4", .data = _rproc_cfg_imx6sx },
+ { .compatible = "fsl,imx8mq-cm4", .data = _rproc_cfg_imx8mq },
+ { .compatible = "fsl,imx8mm-cm4", .data = _rproc_cfg_imx8mq },
{},
};
MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
--
2.28.0
[PATCH] octeontx2-af: Remove unneeded semicolon
fix semicolon.cocci warnings: ./drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c:272:2-3: Unneeded semicolon Signed-off-by: Xu Wang --- drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c index 14832b66d1fe..f72c79540b24 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c @@ -269,7 +269,7 @@ static void npc_scan_parse_result(struct npc_mcam *mcam, u8 bit_number, break; default: return; - }; + } npc_set_kw_masks(mcam, type, nr_bits, kwi, offset, intf); } -- 2.17.1
[PATCH V8 09/10] remoteproc: imx_rproc: ignore mapping vdev regions
From: Peng Fan
vdev regions are vdev0vring0, vdev0vring1, vdevbuffer and similar.
They are handled by remoteproc common code, no need to map in imx
rproc driver.
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
drivers/remoteproc/imx_rproc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index fa01e64cc791..54ac143ba033 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -417,6 +417,9 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
struct resource res;
node = of_parse_phandle(np, "memory-region", a);
+ /* Not map vdev region */
+ if (!strcmp(node->name, "vdev"))
+ continue;
err = of_address_to_resource(node, 0, );
if (err) {
dev_err(dev, "unable to resolve memory region\n");
--
2.28.0
[PATCH V8 10/10] remoteproc: imx_proc: enable virtio/mailbox
From: Peng Fan
Use virtio/mailbox to build connection between Remote Proccessors
and Linux. Add work queue to handle incoming messages.
Reviewed-by: Richard Zhu
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 116 -
1 file changed, 113 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 54ac143ba033..c16a91f8e410 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -15,6 +16,9 @@
#include
#include
#include
+#include
+
+#include "remoteproc_internal.h"
#define IMX7D_SRC_SCR 0x0C
#define IMX7D_ENABLE_M4BIT(3)
@@ -86,6 +90,11 @@ struct imx_rproc {
const struct imx_rproc_dcfg *dcfg;
struct imx_rproc_memmem[IMX7D_RPROC_MEM_MAX];
struct clk *clk;
+ struct mbox_client cl;
+ struct mbox_chan*tx_ch;
+ struct mbox_chan*rx_ch;
+ struct work_struct rproc_work;
+ struct workqueue_struct *workqueue;
};
static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -366,9 +375,33 @@ static int imx_rproc_parse_fw(struct rproc *rproc, const
struct firmware *fw)
return 0;
}
+static void imx_rproc_kick(struct rproc *rproc, int vqid)
+{
+ struct imx_rproc *priv = rproc->priv;
+ int err;
+ __u32 mmsg;
+
+ if (!priv->tx_ch) {
+ dev_err(priv->dev, "No initialized mbox tx channel\n");
+ return;
+ }
+
+ /*
+* Send the index of the triggered virtqueue as the mu payload.
+* Let remote processor know which virtqueue is used.
+*/
+ mmsg = vqid << 16;
+
+ err = mbox_send_message(priv->tx_ch, (void *));
+ if (err < 0)
+ dev_err(priv->dev, "%s: failed (%d, err:%d)\n",
+ __func__, vqid, err);
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
+ .kick = imx_rproc_kick,
.da_to_va = imx_rproc_da_to_va,
.load = rproc_elf_load_segments,
.parse_fw = imx_rproc_parse_fw,
@@ -444,6 +477,66 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
return 0;
}
+static void imx_rproc_vq_work(struct work_struct *work)
+{
+ struct imx_rproc *priv = container_of(work, struct imx_rproc,
+ rproc_work);
+
+ rproc_vq_interrupt(priv->rproc, 0);
+ rproc_vq_interrupt(priv->rproc, 1);
+}
+
+static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
+{
+ struct rproc *rproc = dev_get_drvdata(cl->dev);
+ struct imx_rproc *priv = rproc->priv;
+
+ queue_work(priv->workqueue, >rproc_work);
+}
+
+static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device *dev = priv->dev;
+ struct mbox_client *cl;
+ int ret;
+
+ if (!of_get_property(dev->of_node, "mbox-names", NULL))
+ return 0;
+
+ cl = >cl;
+ cl->dev = dev;
+ cl->tx_block = true;
+ cl->tx_tout = 100;
+ cl->knows_txdone = false;
+ cl->rx_callback = imx_rproc_rx_callback;
+
+ priv->tx_ch = mbox_request_channel_byname(cl, "tx");
+ if (IS_ERR(priv->tx_ch)) {
+ ret = PTR_ERR(priv->tx_ch);
+ return dev_err_probe(cl->dev, ret,
+"failed to request tx mailbox channel:
%d\n", ret);
+ }
+
+ priv->rx_ch = mbox_request_channel_byname(cl, "rx");
+ if (IS_ERR(priv->rx_ch)) {
+ mbox_free_channel(priv->tx_ch);
+ ret = PTR_ERR(priv->rx_ch);
+ return dev_err_probe(cl->dev, ret,
+"failed to request rx mailbox channel:
%d\n", ret);
+ }
+
+ return 0;
+}
+
+static void imx_rproc_free_mbox(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+
+ mbox_free_channel(priv->tx_ch);
+ mbox_free_channel(priv->rx_ch);
+}
+
static int imx_rproc_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -481,18 +574,28 @@ static int imx_rproc_probe(struct platform_device *pdev)
priv->dev = dev;
dev_set_drvdata(dev, rproc);
+ priv->workqueue = create_workqueue(dev_name(dev));
+ if (!priv->workqueue) {
+ dev_err(dev, "cannot create workqueue\n");
+ ret = -ENOMEM;
+ goto err_put_rproc;
+ }
+
+ ret = imx_rproc_xtr_mbox_init(rproc);
+ if (ret)
+ goto err_put_wkq;
ret = imx_rproc_addr_init(priv, pdev);
if (ret) {
[PATCH V8 05/10] remoteproc: imx_rproc: correct err message
From: Peng Fan
It is using devm_ioremap, so not devm_ioremap_resource. Correct
the error message and print out sa/size.
Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6603e00bb6f4..2a093cea4997 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -268,7 +268,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap(>dev,
att->sa, att->size);
if (!priv->mem[b].cpu_addr) {
- dev_err(dev, "devm_ioremap_resource failed\n");
+ dev_err(dev, "failed to remap %#x bytes from %#x\n",
att->size, att->sa);
return -ENOMEM;
}
priv->mem[b].sys_addr = att->sa;
@@ -298,7 +298,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap_resource(>dev, );
if (IS_ERR(priv->mem[b].cpu_addr)) {
- dev_err(dev, "devm_ioremap_resource failed\n");
+ dev_err(dev, "failed to remap %pr\n", );
err = PTR_ERR(priv->mem[b].cpu_addr);
return err;
}
--
2.28.0
[PATCH V8 02/10] dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M support
From: Peng Fan
Add i.MX8MQ/M support, also include mailbox for rpmsg/virtio usage.
Signed-off-by: Peng Fan
---
.../bindings/remoteproc/fsl,imx-rproc.yaml| 49 +++
1 file changed, 49 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index bce6ccfe1538..b0d600baa161 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -15,6 +15,8 @@ maintainers:
properties:
compatible:
enum:
+ - fsl,imx8mq-cm4
+ - fsl,imx8mm-cm4
- fsl,imx7d-cm4
- fsl,imx6sx-cm4
@@ -26,6 +28,20 @@ properties:
description:
Phandle to syscon block which provide access to System Reset Controller
+ mbox-names:
+items:
+ - const: tx
+ - const: rx
+ - const: rxdb
+
+ mboxes:
+description:
+ This property is required only if the rpmsg/virtio functionality is used.
+ List of < type channel> - 1 channel for TX, 1 channel for RX, 1
channel for RXDB.
+ (see mailbox/fsl,mu.yaml)
+minItems: 1
+maxItems: 3
+
memory-region:
description:
list of phandels to the reserved memory regions.
@@ -56,4 +72,37 @@ examples:
clocks = < IMX7D_ARM_M4_ROOT_CLK>;
};
+ - |
+#include
+rsc_table: rsc_table@550ff000 {
+ no-map;
+ reg = <0x550ff000 0x1000>;
+};
+
+vdev0vring0: vdev0vring0@5500 {
+ no-map;
+ reg = <0x5500 0x8000>;
+};
+
+vdev0vring1: vdev0vring1@55008000 {
+ reg = <0x55008000 0x8000>;
+ no-map;
+};
+
+vdev0buffer: vdev0buffer@5540 {
+ compatible = "shared-dma-pool";
+ reg = <0x5540 0x10>;
+ no-map;
+};
+
+imx8mm-cm4 {
+ compatible = "fsl,imx8mm-cm4";
+ clocks = < IMX8MM_CLK_M4_DIV>;
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = < 0 1
+ 1 1
+ 3 1>;
+ memory-region = <>, <>, <>,
<_table>;
+ syscon = <>;
+};
...
--
2.28.0
[PATCH V8 04/10] remoteproc: add is_iomem to da_to_va
From: Peng Fan
Introduce an extra parameter is_iomem to da_to_va, then the caller
could take the memory as normal memory or io mapped memory.
Reviewed-by: Bjorn Andersson
Reviewed-by: Mathieu Poirier
Reported-by: kernel test robot
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 2 +-
drivers/remoteproc/ingenic_rproc.c | 2 +-
drivers/remoteproc/keystone_remoteproc.c | 2 +-
drivers/remoteproc/mtk_scp.c | 6 +++---
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/remoteproc/pru_rproc.c | 2 +-
drivers/remoteproc/qcom_q6v5_adsp.c| 2 +-
drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
drivers/remoteproc/qcom_q6v5_wcss.c| 2 +-
drivers/remoteproc/qcom_wcnss.c| 2 +-
drivers/remoteproc/remoteproc_core.c | 7 +--
drivers/remoteproc/remoteproc_coredump.c | 8 ++--
drivers/remoteproc/remoteproc_debugfs.c| 2 +-
drivers/remoteproc/remoteproc_elf_loader.c | 21 +++--
drivers/remoteproc/remoteproc_internal.h | 2 +-
drivers/remoteproc/st_slim_rproc.c | 2 +-
drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +-
drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +-
drivers/remoteproc/wkup_m3_rproc.c | 2 +-
include/linux/remoteproc.h | 2 +-
20 files changed, 45 insertions(+), 29 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 8957ed271d20..6603e00bb6f4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -208,7 +208,7 @@ static int imx_rproc_da_to_sys(struct imx_rproc *priv, u64
da,
return -ENOENT;
}
-static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *imx_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len, bool
*is_iomem)
{
struct imx_rproc *priv = rproc->priv;
void *va = NULL;
diff --git a/drivers/remoteproc/ingenic_rproc.c
b/drivers/remoteproc/ingenic_rproc.c
index 26e19e6143b7..bb5049295576 100644
--- a/drivers/remoteproc/ingenic_rproc.c
+++ b/drivers/remoteproc/ingenic_rproc.c
@@ -116,7 +116,7 @@ static void ingenic_rproc_kick(struct rproc *rproc, int
vqid)
writel(vqid, vpu->aux_base + REG_CORE_MSG);
}
-static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *ingenic_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len,
bool *is_iomem)
{
struct vpu *vpu = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/keystone_remoteproc.c
b/drivers/remoteproc/keystone_remoteproc.c
index cd266163a65f..54781f553f4e 100644
--- a/drivers/remoteproc/keystone_remoteproc.c
+++ b/drivers/remoteproc/keystone_remoteproc.c
@@ -246,7 +246,7 @@ static void keystone_rproc_kick(struct rproc *rproc, int
vqid)
* can be used either by the remoteproc core for loading (when using kernel
* remoteproc loader), or by any rpmsg bus drivers.
*/
-static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *keystone_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len,
bool *is_iomem)
{
struct keystone_rproc *ksproc = rproc->priv;
void __iomem *va = NULL;
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index e0c235690361..535175f013e4 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -270,7 +270,7 @@ static int scp_elf_load_segments(struct rproc *rproc, const
struct firmware *fw)
}
/* grab the kernel address for this device address */
- ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz);
+ ptr = (void __iomem *)rproc_da_to_va(rproc, da, memsz, NULL);
if (!ptr) {
dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
ret = -EINVAL;
@@ -458,7 +458,7 @@ static int scp_start(struct rproc *rproc)
return ret;
}
-static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len)
+static void *scp_da_to_va(struct rproc *rproc, u64 da, size_t len, bool
*is_iomem)
{
struct mtk_scp *scp = (struct mtk_scp *)rproc->priv;
int offset;
@@ -587,7 +587,7 @@ void *scp_mapping_dm_addr(struct mtk_scp *scp, u32 mem_addr)
{
void *ptr;
- ptr = scp_da_to_va(scp->rproc, mem_addr, 0);
+ ptr = scp_da_to_va(scp->rproc, mem_addr, 0, NULL);
if (!ptr)
return ERR_PTR(-EINVAL);
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index d94b7391bf9d..43531caa1959 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -728,7 +728,7 @@ static int omap_rproc_stop(struct rproc *rproc)
* Return: translated virtual address in kernel memory space on success,
* or NULL on failure.
*/
-static void *omap_rproc_da_to_va(struct rproc *rproc, u64 da, size_t len)
[PATCH V8 01/10] dt-bindings: remoteproc: convert imx rproc bindings to json-schema
From: Peng Fan
Convert the imx rproc binding to DT schema format using json-schema.
Signed-off-by: Peng Fan
---
.../bindings/remoteproc/fsl,imx-rproc.yaml| 59 +++
.../bindings/remoteproc/imx-rproc.txt | 33 ---
2 files changed, 59 insertions(+), 33 deletions(-)
create mode 100644
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
delete mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
new file mode 100644
index ..bce6ccfe1538
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: NXP iMX6SX/iMX7D Co-Processor Bindings
+
+description:
+ This binding provides support for ARM Cortex M4 Co-processor found on some
NXP iMX SoCs.
+
+maintainers:
+ - Peng Fan
+
+properties:
+ compatible:
+enum:
+ - fsl,imx7d-cm4
+ - fsl,imx6sx-cm4
+
+ clocks:
+description:
+ Clock for co-processor (See ../clock/clock-bindings.txt)
+
+ syscon:
+description:
+ Phandle to syscon block which provide access to System Reset Controller
+
+ memory-region:
+description:
+ list of phandels to the reserved memory regions.
+ (see ../reserved-memory/reserved-memory.txt)
+
+required:
+ - compatible
+ - clocks
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+m4_reserved_sysmem1: cm4@8000 {
+ reg = <0x8000 0x8>;
+};
+
+m4_reserved_sysmem2: cm4@8100 {
+ reg = <0x8100 0x8>;
+};
+
+imx7d-cm4 {
+ compatible = "fsl,imx7d-cm4";
+ memory-region= <_reserved_sysmem1>, <_reserved_sysmem2>;
+ syscon = <>;
+ clocks = < IMX7D_ARM_M4_ROOT_CLK>;
+};
+
+...
diff --git a/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
b/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
deleted file mode 100644
index fbcefd965dc4..
--- a/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-NXP iMX6SX/iMX7D Co-Processor Bindings
-
-
-This binding provides support for ARM Cortex M4 Co-processor found on some
-NXP iMX SoCs.
-
-Required properties:
-- compatible Should be one of:
- "fsl,imx7d-cm4"
- "fsl,imx6sx-cm4"
-- clocks Clock for co-processor (See:
../clock/clock-bindings.txt)
-- syscon Phandle to syscon block which provide access to
- System Reset Controller
-
-Optional properties:
-- memory-regionlist of phandels to the reserved memory regions.
- (See: ../reserved-memory/reserved-memory.txt)
-
-Example:
- m4_reserved_sysmem1: cm4@8000 {
- reg = <0x8000 0x8>;
- };
-
- m4_reserved_sysmem2: cm4@8100 {
- reg = <0x8100 0x8>;
- };
-
- imx7d-cm4 {
- compatible = "fsl,imx7d-cm4";
- memory-region = <_reserved_sysmem1>,
<_reserved_sysmem2>;
- syscon = <>;
- clocks = < IMX7D_ARM_M4_ROOT_CLK>;
- };
--
2.28.0
Re: [PATCH v6 11/16] scripts: kernel-doc: validate kernel-doc markup with the actual names
Em Mon, 18 Jan 2021 13:35:45 -0700 Jonathan Corbet escreveu: > On Thu, 14 Jan 2021 09:04:47 +0100 > Mauro Carvalho Chehab wrote: > > > Kernel-doc currently expects that the kernel-doc markup to come > > just before the function/enum/struct/union/typedef prototype. > > > > Yet, if it find things like: > > > > /** > > * refcount_add - add a value to a refcount > > * @i: the value to add to the refcount > > * @r: the refcount > > */ > > static inline void __refcount_add(int i, refcount_t *r, int *oldp); > > static inline void refcount_add(int i, refcount_t *r); > > > > Kernel-doc will do the wrong thing: > > > > foobar.h:6: warning: Function parameter or member 'oldp' not described > > in '__refcount_add' > > .. c:function:: void __refcount_add (int i, refcount_t *r, int *oldp) > > > >add a value to a refcount > > > > **Parameters** > > > > ``int i`` > > the value to add to the refcount > > > > ``refcount_t *r`` > > the refcount > > > > ``int *oldp`` > > *undescribed* > > > > Basically, it will document "__refcount_add" with the kernel-doc > > markup for refcount_add. > > > > If both functions have the same arguments, this won't even > > produce any warning! > > > > Add a logic to check if the kernel-doc identifier matches the actual > > name of the C function or data structure that will be documented. > > > > Signed-off-by: Mauro Carvalho Chehab > > I've applied this one; Thanks! > it seems useful to have even if it creates more > warnings that Stephen will duly email me about tomorrow...:) I have parts > 1-10 set aside and will apply any that don't get picked up directly by the > maintainers involved. Yeah, new warnings are unavoidable, as new patches may be introducing extra issues. Hopefully, the new warning will help people to detect the issue earlier before submitting upstream. Thanks, Mauro
Re: [PATCH] xen-blkfront: don't make discard-alignment mandatory
On 18.01.21 16:15, Roger Pau Monne wrote:
Don't require the discard-alignment xenstore node to be present in
order to correctly setup the feature. This can happen with versions of
QEMU that only write the discard-granularity but not the
discard-alignment node.
Assume discard-alignment is 0 if not present. While there also fix the
logic to not enable the discard feature if discard-granularity is not
present.
Reported-by: Arthur Borsboom
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Jens Axboe
Cc: xen-de...@lists.xenproject.org
Cc: linux-bl...@vger.kernel.org
Cc: Arthur Borsboom
---
drivers/block/xen-blkfront.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5265975b3fba..5a93f7cc2939 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2179,22 +2179,23 @@ static void blkfront_closing(struct blkfront_info *info)
static void blkfront_setup_discard(struct blkfront_info *info)
{
- int err;
- unsigned int discard_granularity;
- unsigned int discard_alignment;
+ unsigned int discard_granularity = 0;
+ unsigned int discard_alignment = 0;
+ unsigned int discard_secure = 0;
- info->feature_discard = 1;
- err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+ xenbus_gather(XBT_NIL, info->xbdev->otherend,
"discard-granularity", "%u", _granularity,
"discard-alignment", "%u", _alignment,
+ "discard-secure", "%u", _secure,
NULL);
This would mean that "discard-secure" will be evaluated only if the
other two items are set in Xenstore. From blkif.h I can't see this is
required, and your patch is modifying today's behavior in this regard.
You might want to have three xenbus_read_unsigned() calls instead.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] venus: core: Fix platform driver shutdown
On Mon, Dec 21, 2020 at 11:58:20AM +0200, Stanimir Varbanov wrote:
> With TZ system reboot cannot finish successfully. To fix that
> enable core clocks by runtime pm before TZ calls and disable
> clocks after that.
>
> Fixes: 7399139be6b2 ("media: venus: core: add shutdown callback for venus")
> Signed-off-by: Stanimir Varbanov
Hi Mauro,
Could you help pick this fix up?
Shawn
> ---
> drivers/media/platform/qcom/venus/core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index bdd293faaad0..7233a7311757 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -349,8 +349,10 @@ static void venus_core_shutdown(struct platform_device
> *pdev)
> {
> struct venus_core *core = platform_get_drvdata(pdev);
>
> + pm_runtime_get_sync(core->dev);
> venus_shutdown(core);
> venus_firmware_deinit(core);
> + pm_runtime_put_sync(core->dev);
> }
>
> static __maybe_unused int venus_runtime_suspend(struct device *dev)
> --
> 2.17.1
>
Re: linux-next: boot failure after merge of the iomem-mmap-vs-gup tree
On Tue, Jan 19, 2021 at 6:26 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Wed, 13 Jan 2021 16:29:48 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the iomem-mmap-vs-gup tree, today's linux-next boot test
> > (powerpc pseries_le_defconfig) failed like this:
> >
> > EEH: pSeries platform initialized
> > PCI: Probing PCI hardware
> > BUG: Kernel NULL pointer dereference on write at 0x0030
> > Faulting instruction address: 0xc013bf4c
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc3 #2
> > NIP: c013bf4c LR: c07a9ee8 CTR:
> > REGS: c63a3610 TRAP: 0380 Not tainted (5.11.0-rc3)
> > MSR: 82009033 CR: 84002440 XER:
> >
> > CFAR: c07a9ee4 IRQMASK: 0
> > GPR00: c07a9ee8 c63a38b0 c13d8100
> > c6061300
> > GPR04: 0b20 c0f11738
> >
> > GPR08: c07a7ab0 c07a7a40
> > 2d6770696f73
> > GPR12: c15b c0013120
> >
> > GPR16:
> >
> > GPR20:
> >
> > GPR24: c6210de8 c6167120 c6620b20
> >
> > GPR28: c6167120 0180 c6061300
> > c6167000
> > NIP [c013bf4c] iomem_get_mapping+0x1c/0x30
> > LR [c07a9ee8] pci_create_legacy_files+0xa8/0x1c0
> > Call Trace:
> > [c63a38b0] [c07a9e84]
> > pci_create_legacy_files+0x44/0x1c0 (unreliable)
> > [c63a3930] [c0795198]
> > pci_register_host_bridge+0x288/0x510
> > [c63a3a60] [c0795514] pci_create_root_bus+0xf4/0x150
> > [c63a3ac0] [c006d424] pcibios_scan_phb+0xe4/0x270
> > [c63a3b70] [c1010b40] pcibios_init+0x8c/0x128
> > [c63a3bf0] [c0012b70] do_one_initcall+0x60/0x2c0
> > [c63a3cc0] [c10046b4] kernel_init_freeable+0x2e8/0x380
> > [c63a3da0] [c0013144] kernel_init+0x2c/0x168
> > [c63a3e10] [c000dff0] ret_from_kernel_thread+0x5c/0x6c
> > Instruction dump:
> > 7c634850 4e800020 6000 6000 6042 3c4c012a 3842c1d0 7c0802a6
> > 6000 3d22000d e929caf8 7c2004ac 4e800020 6000
> > 6000
> > ---[ end trace 77f55ece72f02708 ]---
> >
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
> >
> > Caused by commit
> >
> > 85482fbab59e ("PCI: Revoke mappings like devmem")
> >
> > Reverting that commit fixes the boot, so I have done that for today.
>
> I am still reverting this commit.
Thanks for the reminder, I missed your earlier report. I don't have a
machine here with HAVE_PCI_LEGACY, but I think I understand what's
going on here. I'll drop the last two patches from the branch for now
(since both need to be changed to address this somehow).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/2] powerpc/cacheinfo: Lookup cache by dt node and thread-group id
From: "Gautham R. Shenoy"
Currently the cacheinfo code on powerpc indexes the "cache" objects
(modelling the L1/L2/L3 caches) where the key is device-tree node
corresponding to that cache. On some of the POWER server platforms
thread-groups within the core share different sets of caches (Eg: On
SMT8 POWER9 systems, threads 0,2,4,6 of a core share L1 cache and
threads 1,3,5,7 of the same core share another L1 cache). On such
platforms, there is a single device-tree node corresponding to that
cache and the cache-configuration within the threads of the core is
indicated via "ibm,thread-groups" device-tree property.
Since the current code is not aware of the "ibm,thread-groups"
property, on the aforementoined systems, cacheinfo code still treats
all the threads in the core to be sharing the cache because of the
single device-tree node (In the earlier example, the cacheinfo code
would says CPUs 0-7 share L1 cache).
In this patch, we make the powerpc cacheinfo code aware of the
"ibm,thread-groups" property. We indexe the "cache" objects by the
key-pair (device-tree node, thread-group id). For any CPUX, for a
given level of cache, the thread-group id is defined to be the first
CPU in the "ibm,thread-groups" cache-group containing CPUX. For levels
of cache which are not represented in "ibm,thread-groups" property,
the thread-group id is -1.
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/include/asm/smp.h | 3 ++
arch/powerpc/kernel/cacheinfo.c | 80 +
2 files changed, 61 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index c4e2d53..39de24b 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -32,6 +32,9 @@
extern int cpu_to_chip_id(int cpu);
+DECLARE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
+DECLARE_PER_CPU(cpumask_var_t, thread_group_l2_cache_map);
+
#ifdef CONFIG_SMP
struct smp_ops_t {
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 6f903e9a..5a6925d 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -120,6 +120,7 @@ struct cache {
struct cpumask shared_cpu_map; /* online CPUs using this cache */
int type; /* split cache disambiguation */
int level; /* level not explicit in device tree */
+ int group_id; /* id of the group of threads that share
this cache */
struct list_head list; /* global list of cache objects */
struct cache *next_local; /* next cache of >= level */
};
@@ -142,22 +143,24 @@ static const char *cache_type_string(const struct cache
*cache)
}
static void cache_init(struct cache *cache, int type, int level,
- struct device_node *ofnode)
+ struct device_node *ofnode, int group_id)
{
cache->type = type;
cache->level = level;
cache->ofnode = of_node_get(ofnode);
+ cache->group_id = group_id;
INIT_LIST_HEAD(>list);
list_add(>list, _list);
}
-static struct cache *new_cache(int type, int level, struct device_node *ofnode)
+static struct cache *new_cache(int type, int level,
+ struct device_node *ofnode, int group_id)
{
struct cache *cache;
cache = kzalloc(sizeof(*cache), GFP_KERNEL);
if (cache)
- cache_init(cache, type, level, ofnode);
+ cache_init(cache, type, level, ofnode, group_id);
return cache;
}
@@ -309,20 +312,24 @@ static struct cache *cache_find_first_sibling(struct
cache *cache)
return cache;
list_for_each_entry(iter, _list, list)
- if (iter->ofnode == cache->ofnode && iter->next_local == cache)
+ if (iter->ofnode == cache->ofnode &&
+ iter->group_id == cache->group_id &&
+ iter->next_local == cache)
return iter;
return cache;
}
-/* return the first cache on a local list matching node */
-static struct cache *cache_lookup_by_node(const struct device_node *node)
+/* return the first cache on a local list matching node and thread-group id */
+static struct cache *cache_lookup_by_node_group(const struct device_node *node,
+ int group_id)
{
struct cache *cache = NULL;
struct cache *iter;
list_for_each_entry(iter, _list, list) {
- if (iter->ofnode != node)
+ if (iter->ofnode != node ||
+ iter->group_id != group_id)
continue;
cache = cache_find_first_sibling(iter);
break;
@@ -352,14 +359,15 @@ static int cache_is_unified_d(const struct device_node
*np)
CACHE_TYPE_UNIFIED_D : CACHE_TYPE_UNIFIED;
}
-static struct cache
[PATCH] mmc: test: clean up mmc_test_cleanup()
From: Yue Hu
mmc_test_cleanup() has same body as __mmc_test_prepare() with write
except the character to memset().
Signed-off-by: Yue Hu
---
drivers/mmc/core/mmc_test.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c
index f999b48..39a4788 100644
--- a/drivers/mmc/core/mmc_test.c
+++ b/drivers/mmc/core/mmc_test.c
@@ -624,7 +624,7 @@ static unsigned int mmc_test_capacity(struct mmc_card *card)
* Fill the first couple of sectors of the card with known data
* so that bad reads/writes can be detected
*/
-static int __mmc_test_prepare(struct mmc_test_card *test, int write)
+static int __mmc_test_prepare(struct mmc_test_card *test, int write, int val)
{
int ret, i;
@@ -633,7 +633,7 @@ static int __mmc_test_prepare(struct mmc_test_card *test,
int write)
return ret;
if (write)
- memset(test->buffer, 0xDF, 512);
+ memset(test->buffer, val, 512);
else {
for (i = 0; i < 512; i++)
test->buffer[i] = i;
@@ -650,31 +650,17 @@ static int __mmc_test_prepare(struct mmc_test_card *test,
int write)
static int mmc_test_prepare_write(struct mmc_test_card *test)
{
- return __mmc_test_prepare(test, 1);
+ return __mmc_test_prepare(test, 1, 0xDF);
}
static int mmc_test_prepare_read(struct mmc_test_card *test)
{
- return __mmc_test_prepare(test, 0);
+ return __mmc_test_prepare(test, 0, 0);
}
static int mmc_test_cleanup(struct mmc_test_card *test)
{
- int ret, i;
-
- ret = mmc_test_set_blksize(test, 512);
- if (ret)
- return ret;
-
- memset(test->buffer, 0, 512);
-
- for (i = 0; i < BUFFER_SIZE / 512; i++) {
- ret = mmc_test_buffer_transfer(test, test->buffer, i, 512, 1);
- if (ret)
- return ret;
- }
-
- return 0;
+ return __mmc_test_prepare(test, 1, 0);
}
/***/
--
1.9.1
Re: [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control
On Mon, 2021-01-18 at 16:28 +0800, ChiYuan Huang wrote:
> Guenter Roeck 於 2021年1月18日 週一 上午1:43寫道：
> >
> > On 1/15/21 6:13 AM, cy_huang wrote:
> > > From: ChiYuan Huang
> > >
> > > MT6360 not support for TCPC command to control source and sink.
> >
> > does not
> >
> Ack
> > > Uses external 5V vbus regulator as the vbus source control.
> > >
> > Use
> >
> Ack
> > > Also adds the capability to report vsafe0v.
> > >
> > add
> >
> Ack
> > So far this driver works without regulator. Unless I am missing something,
> > this patch makes regulator support mandatory, meaning existing code will
> > fail.
> > I am not sure if that is appropriate/acceptable. Can we be sure that this
> > will
> > work for existing users of this driver ?
> >
> Yes, I already checked all the src/snk functionality based on the
> latest typec code.
> It'll be common for our TCPC. It didn't support for TCPC command.
> From the recent patches, actually, I have the local change to test the
> src capability.
> But I didn't submit it. It's almost the same to add set_vbus callback.
> That's why I submit this change after tcpci 'set_vbus callback' is added.
>
> > Thanks,
> > Guenter
> >
> > > Signed-off-by: ChiYuan Huang
> > > ---
> > > drivers/usb/typec/tcpm/tcpci_mt6360.c | 29 +
> > > 1 file changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > > b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > > index f1bd9e0..0edf4b6 100644
> > > --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > > @@ -11,6 +11,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #include "tcpci.h"
> > > @@ -36,6 +37,7 @@ struct mt6360_tcpc_info {
> > > struct tcpci_data tdata;
> > > struct tcpci *tcpci;
> > > struct device *dev;
> > > + struct regulator *vbus;
> > > int irq;
> > > };
> > >
> > > @@ -51,6 +53,27 @@ static inline int mt6360_tcpc_write16(struct regmap
> > > *regmap,
> > > return regmap_raw_write(regmap, reg, , sizeof(u16));
> > > }
> > >
> > > +static int mt6360_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data
> > > *data, bool src, bool snk)
> > > +{
> > > + struct mt6360_tcpc_info *mti = container_of(data, struct
> > > mt6360_tcpc_info, tdata);
> > > + int ret;
> > > +
> > > + /* To correctly handle the already enabled vbus and disable its
> > > supply first */
> > > + if (regulator_is_enabled(mti->vbus)) {
> > > + ret = regulator_disable(mti->vbus);
> > > + if (ret)
> > > + return ret;
> > > + }
> >
> > Is it really a good idea to disable vbus if it happens to be already enabled
> > and there is (another ?) request to enable it ?
> >
> Yes, for the state change from src_attach_wait to src_attach,
> It need to meet the requirement that the vbus is at vsafe0v.
> So to disable it first is needed.
> And to prevent other users from enabling/disabling external vbus
> regulator in any case.
> I think we may change regulator_get to 'regulator_get_exclusive'.
> From the design, 5v regulator only can be controlled via typec framework.
> If other user touch it, it'll affect the typec state transition.
How about to process the case that even switch usb controller to device
mode, platform also need to keep vbus on? e.g. Iphone Carplay
> > > +
> > > + if (src) {
> > > + ret = regulator_enable(mti->vbus);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data
> > > *tdata)
> > > {
> > > struct regmap *regmap = tdata->regmap;
> > > @@ -138,7 +161,13 @@ static int mt6360_tcpc_probe(struct platform_device
> > > *pdev)
> > > if (mti->irq < 0)
> > > return mti->irq;
> > >
> > > + mti->vbus = devm_regulator_get(>dev, "vbus");
> > > + if (IS_ERR(mti->vbus))
> > > + return PTR_ERR(mti->vbus);
> > > +
> > > mti->tdata.init = mt6360_tcpc_init;
> > > + mti->tdata.set_vbus = mt6360_tcpc_set_vbus;
> > > + mti->tdata.vbus_vsafe0v = 1;
> > > mti->tcpci = tcpci_register_port(>dev, >tdata);
> > > if (IS_ERR(mti->tcpci)) {
> > > dev_err(>dev, "Failed to register tcpci port\n");
> > >
> >
[PATCH 2/2] powerpc/cacheinfo: Remove the redundant get_shared_cpu_map()
From: "Gautham R. Shenoy"
The helper function get_shared_cpu_map() was added in
'commit 500fe5f550ec ("powerpc/cacheinfo: Report the correct
shared_cpu_map on big-cores")'
and subsequently expanded upon in
'commit 0be47634db0b ("powerpc/cacheinfo: Print correct cache-sibling
map/list for L2 cache")'
in order to help report the correct groups of threads sharing these caches
on big-core systems where groups of threads within a core can share
different sets of caches.
Now that powerpc/cacheinfo is aware of "ibm,thread-groups" property,
cache->shared_cpu_map contains the correct set of thread-siblings
sharing the cache. Hence we no longer need the functions
get_shared_cpu_map(). This patch removes this function. We also remove
the helper function index_dir_to_cpu() which was only called by
get_shared_cpu_map().
With these functions removed, we can still see the correct
cache-sibling map/list for L1 and L2 caches on systems with L1 and L2
caches distributed among groups of threads in a core.
With this patch, on a SMT8 POWER10 system where the L1 and L2 caches
are split between the two groups of threads in a core, for CPUs 8,9,
the L1-Data, L1-Instruction, L2, L3 cache CPU sibling list is as
follows:
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10,12,14
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-15
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11,13,15
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-15
$ ppc64_cpu --smt=4
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-11
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-11
$ ppc64_cpu --smt=2
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-9
/sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9
/sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-9
$ ppc64_cpu --smt=1
$ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list
/sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8
/sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/kernel/cacheinfo.c | 41 +
1 file changed, 1 insertion(+), 40 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 5a6925d..20d9169 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -675,45 +675,6 @@ static ssize_t level_show(struct kobject *k, struct
kobj_attribute *attr, char *
static struct kobj_attribute cache_level_attr =
__ATTR(level, 0444, level_show, NULL);
-static unsigned int index_dir_to_cpu(struct cache_index_dir *index)
-{
- struct kobject *index_dir_kobj = >kobj;
- struct kobject *cache_dir_kobj = index_dir_kobj->parent;
- struct kobject *cpu_dev_kobj = cache_dir_kobj->parent;
- struct device *dev = kobj_to_dev(cpu_dev_kobj);
-
- return dev->id;
-}
-
-/*
- * On big-core systems, each core has two groups of CPUs each of which
- * has its own L1-cache. The thread-siblings which share l1-cache with
- * @cpu can be obtained via cpu_smallcore_mask().
- *
- * On some big-core systems, the L2 cache is shared only between some
- * groups of siblings. This is already parsed and encoded in
- * cpu_l2_cache_mask().
- *
- * TODO: cache_lookup_or_instantiate() needs to be made aware of the
- * "ibm,thread-groups" property so that cache->shared_cpu_map
- * reflects the correct siblings on platforms that have this
- * device-tree property. This helper function is only a stop-gap
- * solution so that we report the correct siblings to the
- * userspace via sysfs.
- */
-static
[PATCH 0/2] powerpc/cacheinfo: Add "ibm,thread-groups" awareness
From: "Gautham R. Shenoy" Hi, Currently the cacheinfo code on powerpc indexes the "cache" objects (modelling the L1/L2/L3 caches) where the key is device-tree node corresponding to that cache. On some of the POWER server platforms thread-groups within the core share different sets of caches (Eg: On SMT8 POWER9 systems, threads 0,2,4,6 of a core share L1 cache and threads 1,3,5,7 of the same core share another L1 cache). On such platforms, there is a single device-tree node corresponding to that cache and the cache-configuration within the threads of the core is indicated via "ibm,thread-groups" device-tree property. Since the current code is not aware of the "ibm,thread-groups" property, on the aforementoined systems, cacheinfo code still treats all the threads in the core to be sharing the cache because of the single device-tree node (In the earlier example, the cacheinfo code would says CPUs 0-7 share L1 cache). In this patch series, we make the powerpc cacheinfo code aware of the "ibm,thread-groups" property. We indexe the "cache" objects by the key-pair (device-tree node, thread-group id). For any CPUX, for a given level of cache, the thread-group id is defined to be the first CPU in the "ibm,thread-groups" cache-group containing CPUX. For levels of cache which are not represented in "ibm,thread-groups" property, the thread-group id is -1. We can now remove the helper function get_shared_cpu_map() and index_dir_to_cpu() since the cache->shared_cpu_map contains the correct satate of the thread-siblings sharing the cache. This has been tested on a SMT8 POWER9 system where L1 cache is split between groups of threads in the core and on an SMT8 POWER10 system where L1 and L2 caches are split between groups of threads in a core. With this patch series, on POWER10 SMT8 system, we see the following reported via sysfs: $ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10,12,14 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10,12,14 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10,12,14 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-15 /sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11,13,15 /sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11,13,15 /sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11,13,15 /sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-15 $ ppc64_cpu --smt=4 $ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8,10 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8,10 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8,10 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-11 /sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9,11 /sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9,11 /sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9,11 /sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-11 $ ppc64_cpu --smt=2 $ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8-9 /sys/devices/system/cpu/cpu9/cache/index0/shared_cpu_list:9 /sys/devices/system/cpu/cpu9/cache/index1/shared_cpu_list:9 /sys/devices/system/cpu/cpu9/cache/index2/shared_cpu_list:9 /sys/devices/system/cpu/cpu9/cache/index3/shared_cpu_list:8-9 $ ppc64_cpu --smt=1 $ grep . /sys/devices/system/cpu/cpu[89]/cache/index[0123]/shared_cpu_list /sys/devices/system/cpu/cpu8/cache/index0/shared_cpu_list:8 /sys/devices/system/cpu/cpu8/cache/index1/shared_cpu_list:8 /sys/devices/system/cpu/cpu8/cache/index2/shared_cpu_list:8 /sys/devices/system/cpu/cpu8/cache/index3/shared_cpu_list:8 Gautham R. Shenoy (2): powerpc/cacheinfo: Lookup cache by dt node and thread-group id powerpc/cacheinfo: Remove the redundant get_shared_cpu_map() arch/powerpc/include/asm/smp.h | 3 + arch/powerpc/kernel/cacheinfo.c | 121 2 files changed, 62 insertions(+), 62 deletions(-) -- 1.9.4
Re: [PATCH] usb: gadget: u_serial: Remove old tasklet comments
Davidlohr Bueso writes: > Update old comments as of 8b4c62aef6f (usb: gadget: u_serial: process RX > in workqueue instead of tasklet). > > Signed-off-by: Davidlohr Bueso Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
Re: [PATCH v2] rtlwifi: rtl8192se: Simplify bool comparison.
On Tue, 2021-01-19 at 14:32 +0800, Jiapeng Zhong wrote: > Fix the follow coccicheck warnings: > > ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27: > WARNING: Comparison of 0/1 to bool variable. > > ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26: > WARNING: Comparison of 0/1 to bool variable. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Zhong > --- > Changes in v2: > -Modified subject. > You forget to remove the period at the end of subject. i.e. "rtlwifi: rtl8192se: Simplify bool comparison" --- Ping-Ke
RE: [PATCH] cfg80211: Fix "suspicious RCU usage in wiphy_apply_custom_regulatory" warning/backtrace
> -Original Message-
> From: Hans de Goede
> Sent: Monday, January 18, 2021 23:09
> To: Peer, Ilan ; Johannes Berg
> ; David S . Miller ;
> Jakub Kicinski ; Rojewski, Cezary
> ; Pierre-Louis Bossart louis.boss...@linux.intel.com>; Liam Girdwood
> ; Jie Yang ;
> Mark Brown
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; alsa-de...@alsa-project.org
> Subject: Re: [PATCH] cfg80211: Fix "suspicious RCU usage in
> wiphy_apply_custom_regulatory" warning/backtrace
>
> Hi,
>
> On 1/5/21 10:24 AM, Peer, Ilan wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Hans de Goede
> >> Sent: Monday, January 04, 2021 19:07
> >> To: Johannes Berg ; David S . Miller
> >> ; Jakub Kicinski ; Rojewski,
> >> Cezary ; Pierre-Louis Bossart >> louis.boss...@linux.intel.com>; Liam Girdwood
> >> ; Jie Yang
> >> ; Mark Brown
> >> Cc: Hans de Goede ; linux-
> >> wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org; alsa-de...@alsa-project.org; Peer, Ilan
> >>
> >> Subject: [PATCH] cfg80211: Fix "suspicious RCU usage in
> >> wiphy_apply_custom_regulatory" warning/backtrace
> >>
> >> Commit beee24695157 ("cfg80211: Save the regulatory domain when
> >> setting custom regulatory") adds a get_wiphy_regdom call to
> >> wiphy_apply_custom_regulatory. But as the comment above
> >> wiphy_apply_custom_regulatory says:
> >> "/* Used by drivers prior to wiphy registration */"
> >> this function is used by driver's probe function before the wiphy is
> >> registered and at this point wiphy->regd will typically by NULL and
> >> calling rcu_dereference_rtnl on a NULL pointer causes the following
> >> warning/backtrace:
> >>
> >> =
> >> WARNING: suspicious RCU usage
> >> 5.11.0-rc1+ #19 Tainted: GW
> >> -
> >> net/wireless/reg.c:144 suspicious rcu_dereference_check() usage!
> >>
> >> other info that might help us debug this:
> >>
> >> rcu_scheduler_active = 2, debug_locks = 1
> >> 2 locks held by kworker/2:0/22:
> >> #0: 9a4bc104df38 ((wq_completion)events){+.+.}-{0:0}, at:
> >> process_one_work+0x1ee/0x570
> >> #1: b6e94010be78
> >> ((work_completion)(_work->work)){+.+.}-{0:0},
> >> at: process_one_work+0x1ee/0x570
> >>
> >> stack backtrace:
> >> CPU: 2 PID: 22 Comm: kworker/2:0 Tainted: GW 5.11.0-rc1+
> >> #19
> >> Hardware name: LENOVO 60073/INVALID, BIOS 01WT17WW 08/01/2014
> >> Workqueue: events request_firmware_work_func Call Trace:
> >> dump_stack+0x8b/0xb0
> >> get_wiphy_regdom+0x57/0x60 [cfg80211]
> >> wiphy_apply_custom_regulatory+0xa0/0xf0 [cfg80211]
> >> brcmf_cfg80211_attach+0xb02/0x1360 [brcmfmac]
> >> brcmf_attach+0x189/0x460 [brcmfmac]
> >> brcmf_sdio_firmware_callback+0x78a/0x8f0 [brcmfmac]
> >> brcmf_fw_request_done+0x67/0xf0 [brcmfmac]
> >> request_firmware_work_func+0x3d/0x70
> >> process_one_work+0x26e/0x570
> >> worker_thread+0x55/0x3c0
> >> ? process_one_work+0x570/0x570
> >> kthread+0x137/0x150
> >> ? __kthread_bind_mask+0x60/0x60
> >> ret_from_fork+0x22/0x30
> >>
> >> Add a check for wiphy->regd being NULL before calling
> >> get_wiphy_regdom (as is already done in other places) to fix this.
> >>
> >> wiphy->regd will likely always be NULL when
> >> wiphy->wiphy_apply_custom_regulatory
> >> gets called, so arguably the tmp = get_wiphy_regdom() and
> >> rcu_free_regdom(tmp) calls should simply be dropped, this patch keeps
> >> the
> >> 2 calls, to allow drivers to call wiphy_apply_custom_regulatory more
> >> then once if necessary.
> >>
> >> Cc: Ilan Peer
> >> Fixes: beee24695157 ("cfg80211: Save the regulatory domain when
> >> setting custom regulator")
> >> Signed-off-by: Hans de Goede
> >> ---
> >> net/wireless/reg.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/net/wireless/reg.c b/net/wireless/reg.c index
> >> bb72447ad960..9254b9cbaa21 100644
> >> --- a/net/wireless/reg.c
> >> +++ b/net/wireless/reg.c
> >> @@ -2547,7 +2547,7 @@ static void handle_band_custom(struct wiphy
> >> *wiphy, void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
> >> const struct ieee80211_regdomain *regd) {
> >> - const struct ieee80211_regdomain *new_regd, *tmp;
> >> + const struct ieee80211_regdomain *new_regd, *tmp = NULL;
> >>enum nl80211_band band;
> >>unsigned int bands_set = 0;
> >>
> >> @@ -2571,7 +2571,8 @@ void wiphy_apply_custom_regulatory(struct
> wiphy
> >> *wiphy,
> >>if (IS_ERR(new_regd))
> >>return;
> >>
> >> - tmp = get_wiphy_regdom(wiphy);
> >> + if (wiphy->regd)
> >> + tmp = get_wiphy_regdom(wiphy);
> >>rcu_assign_pointer(wiphy->regd, new_regd);
> >>rcu_free_regdom(tmp);
> >
> > This only fixes the first case where the pointer in NULL and does not handle
> the wrong RCU usage in other cases.
> >
> > I'll prepare a fix for this.
>
> Any luck with this? This is a regression in 5.11, so this really
[PATCH v2 17/17] MAINTAINERS: Add ROHM BD71815AGW
Add maintainer entries for ROHM BD71815AGW drivers. New regulator and GPIO drivers were introduced for these PMICs. Signed-off-by: Matti Vaittinen --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cc1e6a5ee6e6..248e8023f31a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15332,18 +15332,21 @@ F: Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt F: Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt F: drivers/clk/clk-bd718x7.c F: drivers/gpio/gpio-bd70528.c +F: drivers/gpio/gpio-bd71815.c F: drivers/gpio/gpio-bd71828.c F: drivers/mfd/rohm-bd70528.c F: drivers/mfd/rohm-bd71828.c F: drivers/mfd/rohm-bd718x7.c F: drivers/power/supply/bd70528-charger.c F: drivers/regulator/bd70528-regulator.c +F: drivers/regulator/bd71815-regulator.c F: drivers/regulator/bd71828-regulator.c F: drivers/regulator/bd718x7-regulator.c F: drivers/regulator/rohm-regulator.c F: drivers/rtc/rtc-bd70528.c F: drivers/watchdog/bd70528_wdt.c F: include/linux/mfd/rohm-bd70528.h +F: include/linux/mfd/rohm-bd71815.h F: include/linux/mfd/rohm-bd71828.h F: include/linux/mfd/rohm-bd718x7.h F: include/linux/mfd/rohm-generic.h -- 2.25.4 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
Re: [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control
On Sun, 2021-01-17 at 09:43 -0800, Guenter Roeck wrote:
> On 1/15/21 6:13 AM, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > MT6360 not support for TCPC command to control source and sink.
>
> does not
>
> > Uses external 5V vbus regulator as the vbus source control.
> >
> Use
>
> > Also adds the capability to report vsafe0v.
> >
> add
>
> So far this driver works without regulator. Unless I am missing something,
> this patch makes regulator support mandatory, meaning existing code will fail.
If don't provide vbus-supply in DTS, regulator framework will provide a
dummy regulator, so the code will not fail.
> I am not sure if that is appropriate/acceptable. Can we be sure that this will
> work for existing users of this driver ?
>
> Thanks,
> Guenter
>
> > Signed-off-by: ChiYuan Huang
> > ---
> > drivers/usb/typec/tcpm/tcpci_mt6360.c | 29 +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > index f1bd9e0..0edf4b6 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "tcpci.h"
> > @@ -36,6 +37,7 @@ struct mt6360_tcpc_info {
> > struct tcpci_data tdata;
> > struct tcpci *tcpci;
> > struct device *dev;
> > + struct regulator *vbus;
> > int irq;
> > };
> >
> > @@ -51,6 +53,27 @@ static inline int mt6360_tcpc_write16(struct regmap
> > *regmap,
> > return regmap_raw_write(regmap, reg, , sizeof(u16));
> > }
> >
> > +static int mt6360_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data
> > *data, bool src, bool snk)
> > +{
> > + struct mt6360_tcpc_info *mti = container_of(data, struct
> > mt6360_tcpc_info, tdata);
> > + int ret;
> > +
> > + /* To correctly handle the already enabled vbus and disable its supply
> > first */
> > + if (regulator_is_enabled(mti->vbus)) {
> > + ret = regulator_disable(mti->vbus);
> > + if (ret)
> > + return ret;
> > + }
>
> Is it really a good idea to disable vbus if it happens to be already enabled
> and there is (another ?) request to enable it ?
>
> > +
> > + if (src) {
> > + ret = regulator_enable(mti->vbus);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
> > {
> > struct regmap *regmap = tdata->regmap;
> > @@ -138,7 +161,13 @@ static int mt6360_tcpc_probe(struct platform_device
> > *pdev)
> > if (mti->irq < 0)
> > return mti->irq;
> >
> > + mti->vbus = devm_regulator_get(>dev, "vbus");
> > + if (IS_ERR(mti->vbus))
> > + return PTR_ERR(mti->vbus);
> > +
> > mti->tdata.init = mt6360_tcpc_init;
> > + mti->tdata.set_vbus = mt6360_tcpc_set_vbus;
> > + mti->tdata.vbus_vsafe0v = 1;
> > mti->tcpci = tcpci_register_port(>dev, >tdata);
> > if (IS_ERR(mti->tcpci)) {
> > dev_err(>dev, "Failed to register tcpci port\n");
> >
>
[PATCH v2 09/17] mfd: Support for ROHM BD71815 PMIC core
Add core support for ROHM BD71815 Power Management IC.
The IC integrates regulators, a battery charger with a coulomb counter,
a real-time clock (RTC), clock gate and general-purpose outputs (GPO).
Signed-off-by: Matti Vaittinen
---
Changes since v1:
- Used BIT() for better readability
- removed some unused definitions
drivers/mfd/Kconfig | 15 +-
drivers/mfd/rohm-bd71828.c | 416 +--
include/linux/mfd/rohm-bd71815.h | 561 +++
include/linux/mfd/rohm-bd71828.h | 3 +
4 files changed, 952 insertions(+), 43 deletions(-)
create mode 100644 include/linux/mfd/rohm-bd71815.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bdfce7b15621..59bfacb91898 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1984,19 +1984,20 @@ config MFD_ROHM_BD70528
charger.
config MFD_ROHM_BD71828
- tristate "ROHM BD71828 Power Management IC"
+ tristate "ROHM BD71828 and BD71815 Power Management IC"
depends on I2C=y
depends on OF
select REGMAP_I2C
select REGMAP_IRQ
select MFD_CORE
help
- Select this option to get support for the ROHM BD71828 Power
- Management IC. BD71828GW is a single-chip power management IC for
- battery-powered portable devices. The IC integrates 7 buck
- converters, 7 LDOs, and a 1500 mA single-cell linear charger.
- Also included is a Coulomb counter, a real-time clock (RTC), and
- a 32.768 kHz clock gate.
+ Select this option to get support for the ROHM BD71828 and BD71815
+ Power Management ICs. BD71828GW and BD71815AGW are single-chip power
+ management ICs mainly for battery-powered portable devices.
+ The BD71828 integrates 7 buck converters and 7 LDOs. The BD71815
+ has 5 bucks, 7 LDOs, and a boost for driving LEDs. Both ICs provide
+ also a single-cell linear charger, a Coulomb counter, a real-time
+ clock (RTC), GPIOs and a 32.768 kHz clock gate.
config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
index 210261d026f2..28b82477ce4c 100644
--- a/drivers/mfd/rohm-bd71828.c
+++ b/drivers/mfd/rohm-bd71828.c
@@ -2,7 +2,7 @@
//
// Copyright (C) 2019 ROHM Semiconductors
//
-// ROHM BD71828 PMIC driver
+// ROHM BD71828/BD71815 PMIC driver
#include
#include
@@ -11,7 +11,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -29,12 +31,102 @@ static struct gpio_keys_platform_data
bd71828_powerkey_data = {
.name = "bd71828-pwrkey",
};
-static const struct resource rtc_irqs[] = {
+static const struct resource bd71815_rtc_irqs[] = {
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_RTC0, "bd71815-rtc-alm-0"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_RTC1, "bd71815-rtc-alm-1"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_RTC2, "bd71815-rtc-alm-2"),
+};
+
+static const struct resource bd71828_rtc_irqs[] = {
DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC0, "bd71828-rtc-alm-0"),
DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC1, "bd71828-rtc-alm-1"),
DEFINE_RES_IRQ_NAMED(BD71828_INT_RTC2, "bd71828-rtc-alm-2"),
};
+static struct resource bd71815_power_irqs[] = {
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_RMV, "bd71815-dcin-rmv"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CLPS_OUT, "bd71815-clps-out"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CLPS_IN, "bd71815-clps-in"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_OVP_RES, "bd71815-dcin-ovp-res"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_OVP_DET, "bd71815-dcin-ovp-det"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_MON_RES, "bd71815-dcin-mon-res"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_DCIN_MON_DET, "bd71815-dcin-mon-det"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_UV_RES, "bd71815-vsys-uv-res"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_UV_DET, "bd71815-vsys-uv-det"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_LOW_RES, "bd71815-vsys-low-res"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_LOW_DET, "bd71815-vsys-low-det"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_MON_RES, "bd71815-vsys-mon-res"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_VSYS_MON_RES, "bd71815-vsys-mon-det"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_WDG_TEMP, "bd71815-chg-wdg-temp"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_WDG_TIME, "bd71815-chg-wdg"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_RECHARGE_RES, "bd71815-rechg-res"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_RECHARGE_DET, "bd71815-rechg-det"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_RANGED_TEMP_TRANSITION,
+"bd71815-ranged-temp-transit"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_CHG_STATE_TRANSITION,
+"bd71815-chg-state-change"),
+ DEFINE_RES_IRQ_NAMED(BD71815_INT_BAT_TEMP_NORMAL,
+
Re: [PATCH v6 4/6] mfd: ahc1ec0: Add support for Advantech embedded controller
Campion Kang 於 2021年1月18日 週一 下午8:37寫道：
>
> AHC1EC0 is the embedded controller driver for Advantech industrial
> products. This provides sub-devices such as hwmon and watchdog, and also
> expose functions for sub-devices to read/write the value to embedded
> controller.
>
> Changed since V5:
> - Kconfig: add "AHC1EC0" string to clearly define the EC name
> - fix the code according to reviewer's suggestion
> - remove unnecessary header files
> - change the structure name to lower case, align with others
> naming
>
> Signed-off-by: Campion Kang
> ---
> drivers/mfd/Kconfig | 10 +
> drivers/mfd/Makefile| 2 +
> drivers/mfd/ahc1ec0.c | 808
> include/linux/mfd/ahc1ec0.h | 276
> 4 files changed, 1096 insertions(+)
> create mode 100644 drivers/mfd/ahc1ec0.c
> create mode 100644 include/linux/mfd/ahc1ec0.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index bdfce7b15621..7d5fb5c17d9a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2154,5 +2154,15 @@ config MFD_INTEL_M10_BMC
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_AHC1EC0
> + tristate "Advantech AHC1EC0 Embedded Controller Module"
> + depends on X86
> + select MFD_CORE
> + help
> + This is the core function that for Advantech EC drivers. It
> + includes the sub-devices such as hwmon, watchdog, etc. And also
> + provides expose functions for sub-devices to read/write the value
> + to embedded controller.
> +
> endmenu
> endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 14fdb188af02..a6af9d8825f4 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -268,3 +268,5 @@ obj-$(CONFIG_MFD_KHADAS_MCU)+= khadas-mcu.o
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o
> obj-$(CONFIG_MFD_INTEL_M10_BMC) += intel-m10-bmc.o
> +
> +obj-$(CONFIG_MFD_AHC1EC0) += ahc1ec0.o
> diff --git a/drivers/mfd/ahc1ec0.c b/drivers/mfd/ahc1ec0.c
> new file mode 100644
> index ..015f4307a54e
> --- /dev/null
> +++ b/drivers/mfd/ahc1ec0.c
> @@ -0,0 +1,808 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Advantech embedded controller core driver AHC1EC0
> + *
> + * Copyright 2020 Advantech IIoT Group
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "ahc1ec0"
> +
> +enum {
> + ADVEC_SUBDEV_BRIGHTNESS = 0,
> + ADVEC_SUBDEV_EEPROM,
> + ADVEC_SUBDEV_GPIO,
> + ADVEC_SUBDEV_HWMON,
> + ADVEC_SUBDEV_LED,
> + ADVEC_SUBDEV_WDT,
> + ADVEC_SUBDEV_MAX,
> +};
> +
> +/* Wait IBF (Input Buffer Full) clear */
> +static int ec_wait_write(void)
> +{
> + int i;
> +
> + for (i = 0; i < EC_MAX_TIMEOUT_COUNT; i++) {
> + if ((inb(EC_COMMAND_PORT) & EC_COMMAND_BIT_IBF) == 0)
> + return 0;
> +
> + udelay(EC_RETRY_UDELAY);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> +/* Wait OBF (Output Buffer Full) data ready */
> +static int ec_wait_read(void)
> +{
> + int i;
> +
> + for (i = 0; i < EC_MAX_TIMEOUT_COUNT; i++) {
> + if ((inb(EC_COMMAND_PORT) & EC_COMMAND_BIT_OBF) != 0)
> + return 0;
> +
> + udelay(EC_RETRY_UDELAY);
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> +/* Read data from EC HW RAM, the process is the following:
> + * Step 0. Wait IBF clear to send command
> + * Step 1. Send read command to EC command port
> + * Step 2. Wait IBF clear that means command is got by EC
> + * Step 3. Send read address to EC data port
> + * Step 4. Wait OBF data ready
> + * Step 5. Get data from EC data port
> + */
> +int read_hw_ram(struct adv_ec_platform_data *adv_ec_data, unsigned char
> addr, unsigned char *data)
> +{
> + int ret;
> +
> + mutex_lock(_ec_data->lock);
> +
> + ret = ec_wait_write();
> + if (ret)
> + goto error;
> + outb(EC_HW_RAM_READ, EC_COMMAND_PORT);
> +
> + ret = ec_wait_write();
> + if (ret)
> + goto error;
> + outb(addr, EC_STATUS_PORT);
> +
> + ret = ec_wait_read();
> + if (ret)
> + goto error;
> + *data = inb(EC_STATUS_PORT);
> +
> + mutex_unlock(_ec_data->lock);
> +
> + return ret;
> +
> +error:
> + mutex_unlock(_ec_data->lock);
> + dev_err(adv_ec_data->dev, "%s: Wait for IBF or OBF too long. line:
> %d\n", __func__,
> + __LINE__);
> +
> + return ret;
> +}
> +
> +/* Write data to EC HW RAM
> + * Step 0. Wait IBF clear to send command
> + * Step 1. Send write command to EC command port
> + * Step 2. Wait IBF clear that means command is got
[PATCH v2 16/17] rtc: bd70528: Support RTC on ROHM BD71815
BD71815 contains similar RTC block as BD71828. Only the address offsets
seem different. Support also BD71815 RTC using rtc-bd70528.
Signed-off-by: Matti Vaittinen
---
No changes since v1
drivers/rtc/Kconfig | 6 +++---
drivers/rtc/rtc-bd70528.c | 45 ---
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 6123f9f4fbc9..1e48424a4729 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -501,11 +501,11 @@ config RTC_DRV_M41T80_WDT
watchdog timer in the ST M41T60 and M41T80 RTC chips series.
config RTC_DRV_BD70528
- tristate "ROHM BD70528 PMIC RTC"
- depends on MFD_ROHM_BD70528 && (BD70528_WATCHDOG || !BD70528_WATCHDOG)
+ tristate "ROHM BD70528, BD71815 and BD71828 PMIC RTC"
+ depends on MFD_ROHM_BD71828 || MFD_ROHM_BD70528 && (BD70528_WATCHDOG ||
!BD70528_WATCHDOG)
help
If you say Y here you will get support for the RTC
- block on ROHM BD70528 and BD71828 Power Management IC.
+ block on ROHM BD70528, BD71815 and BD71828 Power Management IC.
This driver can also be built as a module. If so, the module
will be called rtc-bd70528.
diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
index fb4476bb5ab6..6454afca02a6 100644
--- a/drivers/rtc/rtc-bd70528.c
+++ b/drivers/rtc/rtc-bd70528.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -13,6 +14,12 @@
#include
#include
+/*
+ * On BD71828 and BD71815 the ALM0 MASK is 14 bytes after the ALM0
+ * block start
+ */
+#define BD718XX_ALM_EN_OFFSET 14
+
/*
* We read regs RTC_SEC => RTC_YEAR
* this struct is ordered according to chip registers.
@@ -55,6 +62,7 @@ struct bd70528_rtc {
struct regmap *regmap;
struct device *dev;
u8 reg_time_start;
+ u8 bd718xx_alm_block_start;
bool has_rtc_timers;
};
@@ -236,8 +244,8 @@ static int bd71828_set_alarm(struct device *dev, struct
rtc_wkalrm *a)
struct bd71828_rtc_alm alm;
struct bd70528_rtc *r = dev_get_drvdata(dev);
- ret = regmap_bulk_read(r->regmap, BD71828_REG_RTC_ALM_START,
- , sizeof(alm));
+ ret = regmap_bulk_read(r->regmap, r->bd718xx_alm_block_start, ,
+ sizeof(alm));
if (ret) {
dev_err(dev, "Failed to read alarm regs\n");
return ret;
@@ -250,8 +258,8 @@ static int bd71828_set_alarm(struct device *dev, struct
rtc_wkalrm *a)
else
alm.alm_mask |= BD70528_MASK_ALM_EN;
- ret = regmap_bulk_write(r->regmap, BD71828_REG_RTC_ALM_START,
- , sizeof(alm));
+ ret = regmap_bulk_write(r->regmap, r->bd718xx_alm_block_start, ,
+ sizeof(alm));
if (ret)
dev_err(dev, "Failed to set alarm time\n");
@@ -311,8 +319,8 @@ static int bd71828_read_alarm(struct device *dev, struct
rtc_wkalrm *a)
struct bd71828_rtc_alm alm;
struct bd70528_rtc *r = dev_get_drvdata(dev);
- ret = regmap_bulk_read(r->regmap, BD71828_REG_RTC_ALM_START,
- , sizeof(alm));
+ ret = regmap_bulk_read(r->regmap, r->bd718xx_alm_block_start, ,
+ sizeof(alm));
if (ret) {
dev_err(dev, "Failed to read alarm regs\n");
return ret;
@@ -453,8 +461,9 @@ static int bd71828_alm_enable(struct device *dev, unsigned
int enabled)
if (!enabled)
enableval = 0;
- ret = regmap_update_bits(r->regmap, BD71828_REG_RTC_ALM0_MASK,
-BD70528_MASK_ALM_EN, enableval);
+ ret = regmap_update_bits(r->regmap, r->bd718xx_alm_block_start +
+BD718XX_ALM_EN_OFFSET, BD70528_MASK_ALM_EN,
+enableval);
if (ret)
dev_err(dev, "Failed to change alarm state\n");
@@ -524,9 +533,28 @@ static int bd70528_probe(struct platform_device *pdev)
enable_main_irq = true;
rtc_ops = _rtc_ops;
break;
+ case ROHM_CHIP_TYPE_BD71815:
+ irq_name = "bd71815-rtc-alm-0";
+ bd_rtc->reg_time_start = BD71815_REG_RTC_START;
+
+ /*
+* See also BD718XX_ALM_EN_OFFSET:
+* This works for BD71828 and BD71815 as they have same offset
+* between ALM0 start and ALM0_MASK. If new ICs are to be
+* added this requires proper check as ALM0_MASK is not located
+* at the end of ALM0 block - but after all ALM blocks so if
+* amount of ALMs differ the offset to enable/disable is likely
+* to be incorrect and enable/disable must be given as own
+* reg address here.
+*/
+
Re: [PATCH v6 5/6] hwmon: ahc1ec0-hwmon: Add sub-device hwmon for Advantech embedded controller
Campion Kang 於 2021年1月18日 週一 下午8:37寫道：
>
> This is one of sub-device driver for Advantech embedded controller
> AHC1EC0. This driver provides sysfs ABI for Advantech related
> applications to monitor the system status.
>
> Changed since V5:
> - remove unnecessary header files
> - Using [devm_]hwmon_device_register_with_info() to register
> hwmon driver based on reviewer's suggestion
>
> Signed-off-by: Campion Kang
> ---
> drivers/hwmon/Kconfig | 10 +
> drivers/hwmon/Makefile| 1 +
> drivers/hwmon/ahc1ec0-hwmon.c | 660 ++
> 3 files changed, 671 insertions(+)
> create mode 100644 drivers/hwmon/ahc1ec0-hwmon.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 1ecf697d8d99..bfa007026679 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -2139,6 +2139,16 @@ config SENSORS_INTEL_M10_BMC_HWMON
> sensors monitor various telemetry data of different components on
> the
> card, e.g. board temperature, FPGA core temperature/voltage/current.
>
> +config SENSORS_AHC1EC0_HWMON
> + tristate "Advantech AHC1EC0 Hardware Monitor Function"
> + depends on MFD_AHC1EC0
> + help
> + This driver provide support for the hardware monitoring
> functionality
> + for Advantech AHC1EC0 embedded controller on the board.
> +
> + This driver provides the sysfs attributes for applications to
> monitor
> + the system status, including system temperatures, voltages, current.
> +
> if ACPI
>
> comment "ACPI drivers"
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 09a86c5e1d29..0c37747e8c4f 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_SENSORS_ADT7411) += adt7411.o
> obj-$(CONFIG_SENSORS_ADT7462) += adt7462.o
> obj-$(CONFIG_SENSORS_ADT7470) += adt7470.o
> obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
> +obj-$(CONFIG_SENSORS_AHC1EC0_HWMON)+= ahc1ec0-hwmon.o
> obj-$(CONFIG_SENSORS_AMD_ENERGY) += amd_energy.o
> obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
> obj-$(CONFIG_SENSORS_ARM_SCMI) += scmi-hwmon.o
> diff --git a/drivers/hwmon/ahc1ec0-hwmon.c b/drivers/hwmon/ahc1ec0-hwmon.c
> new file mode 100644
> index ..688f07e6a6e0
> --- /dev/null
> +++ b/drivers/hwmon/ahc1ec0-hwmon.c
> @@ -0,0 +1,660 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * HWMON Driver for Advantech Embedded Controller chip AHC1EC0
> + *
> + * Copyright 2020, Advantech IIoT Group
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct ec_hwmon_attrs {
> + const char *name;
> + umode_t mode;
> + int (*read)(struct device *dev, long *val);
> +};
> +
> +struct adv_hwmon_profile {
> + int offset;
> + unsigned long resolution, resolution_vin, resolution_sys,
> resolution_curr, resolution_power;
> + unsigned long r1, r1_vin, r1_sys, r1_curr, r1_power;
> + unsigned long r2, r2_vin, r2_sys, r2_curr, r2_power;
> + int hwmon_in_list_cnt;
> + int temp_list_cnt;
> + int *hwmon_in_list;
> + int *temp_list;
> +};
> +
> +struct ec_hwmon_data {
> + struct device *dev;
> + struct device *hwmon_dev;
> + struct adv_ec_platform_data *adv_ec_data;
> + unsigned long temperature[3];
> + unsigned long ec_current[5];
> + unsigned long power[5];
> + unsigned long voltage[7];
> +
> + struct ec_hw_pin_table pin_tbl;
> + struct ec_smbuso_em0 ec_smboem0;
> + struct adv_hwmon_profile *profile;
> +};
> +
> +static int get_ec_in_vbat_input(struct device *dev, long *val);
> +static int get_ec_in_v5_input(struct device *dev, long *val);
> +static int get_ec_in_v12_input(struct device *dev, long *val);
> +static int get_ec_in_vcore_input(struct device *dev, long *val);
> +static int get_ec_current1_input(struct device *dev, long *val);
> +static int get_ec_cpu_temp(struct device *dev, long *val);
> +static int get_ec_sys_temp(struct device *dev, long *val);
> +
> +const struct ec_hwmon_attrs ec_hwmon_in_attr_template[] = {
> + {"VBAT",0444, get_ec_in_vbat_input},// in1
> + {"5VSB",0444, get_ec_in_v5_input}, // in2
> + {"Vin", 0444, get_ec_in_v12_input}, // in3 (== in8)
> + {"VCORE", 0444, get_ec_in_vcore_input}, // in4
> + {"Vin1",0444, NULL},// in5
> + {"Vin2",0444, NULL},// in6
> + {"System Voltage", 0444, NULL}, // in7
> + {"Current", 0444, get_ec_current1_input},
> +};
> +
> +const struct ec_hwmon_attrs ec_temp_attrs_template[] = {
> + {"CPU Temp",0444, get_ec_cpu_temp},
> + {"System Temp", 0444, get_ec_sys_temp},
> +};
> +
> +enum ec_hwmon_in_type {
> + EC_HWMON_IN_VBAT,
> + EC_HWMON_IN_5VSB,
> +
[PATCH v2 15/17] clk: bd718x7: Add support for clk gate on ROHM BD71815 PMIC
ROHM BD71815 also provide clk signal for RTC. Add control
for gating this clock.
Signed-off-by: Matti Vaittinen
---
Changes since v1:
removed squash-commit leftover from commit message
drivers/clk/clk-bd718x7.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index 17d90e09f1c0..d9e70e506d18 100644
--- a/drivers/clk/clk-bd718x7.c
+++ b/drivers/clk/clk-bd718x7.c
@@ -13,6 +13,8 @@
#include
/* clk control registers */
+/* BD71815 */
+#define BD71815_REG_OUT32K 0x1d
/* BD70528 */
#define BD70528_REG_OUT32K 0x2c
/* BD71828 */
@@ -118,6 +120,10 @@ static int bd71837_clk_probe(struct platform_device *pdev)
c->reg = BD70528_REG_OUT32K;
c->mask = CLK_OUT_EN_MASK;
break;
+ case ROHM_CHIP_TYPE_BD71815:
+ c->reg = BD71815_REG_OUT32K;
+ c->mask = CLK_OUT_EN_MASK;
+ break;
default:
dev_err(>dev, "Unknown clk chip\n");
return -EINVAL;
@@ -146,6 +152,7 @@ static const struct platform_device_id bd718x7_clk_id[] = {
{ "bd71847-clk", ROHM_CHIP_TYPE_BD71847 },
{ "bd70528-clk", ROHM_CHIP_TYPE_BD70528 },
{ "bd71828-clk", ROHM_CHIP_TYPE_BD71828 },
+ { "bd71815-clk", ROHM_CHIP_TYPE_BD71815 },
{ },
};
MODULE_DEVICE_TABLE(platform, bd718x7_clk_id);
@@ -161,6 +168,6 @@ static struct platform_driver bd71837_clk = {
module_platform_driver(bd71837_clk);
MODULE_AUTHOR("Matti Vaittinen ");
-MODULE_DESCRIPTION("BD71837/BD71847/BD70528 chip clk driver");
+MODULE_DESCRIPTION("BD718(15/18/28/37/47/50) and BD70528 chip clk driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:bd718xx-clk");
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Re: [PATCH v6 6/6] watchdog: ahc1ec0-wdt: Add sub-device watchdog for Advantech embedded controller
Campion Kang 於 2021年1月18日 週一 下午8:39寫道：
>
> This is one of sub-device driver for Advantech embedded controller
> AHC1EC0. This driver provide watchdog functionality for Advantech
> related applications to restart the system.
>
> Changed since V5:
> - remove unnecessary header files
> - bug fixed: reboot halt if watchdog enabled
> - Kconfig: add "AHC1EC0" string to clearly define the EC name
>
> Signed-off-by: Campion Kang
> ---
> drivers/watchdog/Kconfig | 11 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/ahc1ec0-wdt.c | 261 +
> 3 files changed, 273 insertions(+)
> create mode 100644 drivers/watchdog/ahc1ec0-wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 7ff941e71b79..1a27836883ac 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1636,6 +1636,17 @@ config NIC7018_WDT
> To compile this driver as a module, choose M here: the module will
> be
> called nic7018_wdt.
>
> +config AHC1EC0_WDT
> + tristate "Advantech AHC1EC0 Watchdog Function"
> + depends on MFD_AHC1EC0
> + help
> + This is sub-device for Advantech AHC1EC0 embedded controller.
> +
> + This driver provide watchdog functionality for Advantech related
> + applications to restart the system.
> + To compile thie driver as a module, choose M here: the module will
> be
> + called ahc1ec0-wdt.
> +
> # M68K Architecture
>
> config M54xx_WATCHDOG
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 5c74ee19d441..7190811b1e50 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -145,6 +145,7 @@ obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
> obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
> obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> +obj-$(CONFIG_AHC1EC0_WDT) += ahc1ec0-wdt.o
> obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
>
> # M68K Architecture
> diff --git a/drivers/watchdog/ahc1ec0-wdt.c b/drivers/watchdog/ahc1ec0-wdt.c
> new file mode 100644
> index ..4497b6106b24
> --- /dev/null
> +++ b/drivers/watchdog/ahc1ec0-wdt.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Watchdog Driver for Advantech Embedded Controller chip AHC1EC0
> + *
> + * Copyright 2020, Advantech IIoT Group
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "ahc1ec0-wdt"
> +
> +struct ec_wdt_data {
> + struct watchdog_device wdtdev;
> + struct adv_ec_platform_data *adv_ec_data;
> + struct notifier_block reboot_nb;
> + struct mutex lock_ioctl;
> + int is_enable;
> + int current_timeout;
> +};
> +
> +#define EC_WDT_MIN_TIMEOUT 1 /* The watchdog devices minimum timeout value
> (in seconds). */
> +#define EC_WDT_MAX_TIMEOUT 600 /* The watchdog devices maximum timeout
> value (in seconds) */
> +#define EC_WDT_DEFAULT_TIMEOUT 45
> +
> +static int set_delay(struct adv_ec_platform_data *adv_ec_data, unsigned
> short delay_timeout_in_ms)
> +{
> + if (write_hw_ram(adv_ec_data, EC_RESET_DELAY_TIME_L,
> delay_timeout_in_ms & 0x00FF)) {
> + pr_err("Failed to set Watchdog Retset Time Low byte.");
> + return -EINVAL;
> + }
> +
> + if (write_hw_ram(adv_ec_data, EC_RESET_DELAY_TIME_H,
> (delay_timeout_in_ms & 0xFF00) >> 8)) {
> + pr_err("Failed to set Watchdog Retset Time Hight byte.");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int advwdt_set_heartbeat(unsigned long t)
> +{
> + if (t < 1 || t > 6553) {
> + pr_err("%s: the input timeout is out of range.", __func__);
> + pr_err("Please choose valid data between 1 ~ 6553.");
> + return -EINVAL;
> + }
> +
> + return (t * 10);
> +}
> +
> +/* Notifier for system down */
> +static int advwdt_notify_sys(struct notifier_block *nb, unsigned long code,
> void *data)
> +{
> + if (code == SYS_DOWN || code == SYS_HALT) {
> + struct ec_wdt_data *ec_wdt_data;
> +
> + ec_wdt_data = container_of(nb, struct ec_wdt_data, reboot_nb);
> + if (!ec_wdt_data)
> + return NOTIFY_BAD;
> +
> + /* Turn the WDT off */
> + if (write_hwram_command(ec_wdt_data->adv_ec_data,
> EC_WDT_STOP)) {
> + pr_err("Failed to set Watchdog stop.");
> + return -EINVAL;
> + }
> + ec_wdt_data->is_enable = 0;
> + pr_info("%s: notify sys shutdown", __func__);
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int ec_wdt_start(struct watchdog_device *wdd)
> +{
> + int ret;
> + int timeout, timeout_in_ms;
> + struct
[PATCH v2 14/17] regulator: Support ROHM BD71815 regulators
Support voltage control for regulators on ROHM BD71815 PMIC.
ROHM BD71815 contains 5 bucks, 7 LDOs and a boost (intended for LED).
Bucks 1 and 2 support HW state based voltage level and enable states. Other
regulators support HW state based enable states. All bucks and LDOs 1-5
allow voltage changes for RUN state and LDO4 can be enabled/disabled via
GPIO.
LDO3 does support changing between two predetermined voltages by using
a GPIO but this functionality is not included in this commit.
This work is derived from driver originally written by Tony Luo
- although not much of original work is left.
Signed-off-by: Matti Vaittinen
---
Changes since v1:
- Staticized probe
- cleaned comments
- removed unused definitions
drivers/regulator/Kconfig | 11 +
drivers/regulator/Makefile| 1 +
drivers/regulator/bd71815-regulator.c | 682 ++
3 files changed, 694 insertions(+)
create mode 100644 drivers/regulator/bd71815-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 5abdd29fb9f3..0646b7183e3f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -205,6 +205,17 @@ config REGULATOR_BD70528
This driver can also be built as a module. If so, the module
will be called bd70528-regulator.
+config REGULATOR_BD71815
+ tristate "ROHM BD71815 Power Regulator"
+ depends on MFD_ROHM_BD71828
+ help
+ This driver supports voltage regulators on ROHM BD71815 PMIC.
+ This will enable support for the software controllable buck
+ and LDO regulators and a current regulator for LEDs.
+
+ This driver can also be built as a module. If so, the module
+ will be called bd71815-regulator.
+
config REGULATOR_BD71828
tristate "ROHM BD71828 Power Regulator"
depends on MFD_ROHM_BD71828
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 680e539f6579..2d18c5246ef6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
obj-$(CONFIG_REGULATOR_BD70528) += bd70528-regulator.o
+obj-$(CONFIG_REGULATOR_BD71815)+= bd71815-regulator.o
obj-$(CONFIG_REGULATOR_BD71828) += bd71828-regulator.o
obj-$(CONFIG_REGULATOR_BD718XX) += bd718x7-regulator.o
obj-$(CONFIG_REGULATOR_BD9571MWV) += bd9571mwv-regulator.o
diff --git a/drivers/regulator/bd71815-regulator.c
b/drivers/regulator/bd71815-regulator.c
new file mode 100644
index ..94f10080a81a
--- /dev/null
+++ b/drivers/regulator/bd71815-regulator.c
@@ -0,0 +1,682 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2014 Embest Technology Co. Ltd. Inc.
+ * bd71815-regulator.c ROHM BD71815 regulator driver
+ *
+ * Author: Tony Luo
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct bd71815_regulator {
+ struct regulator_desc desc;
+ const struct rohm_dvs_config *dvs;
+};
+
+struct bd71815_pmic {
+ struct bd71815_regulator descs[BD71815_REGULATOR_CNT];
+ struct regmap *regmap;
+ struct device *dev;
+ struct gpio_descs *gps;
+ struct regulator_dev *rdev[BD71815_REGULATOR_CNT];
+};
+
+static const int bd7181x_wled_currents[] = {
+ /* 0x00 */
+ 10, 20, 30, 50,
+ 70, 100, 200, 300,
+ 500, 700, 1000, 2000,
+ 3000, 4000, 5000, 6000,
+ /* 0x10 */
+ 7000, 8000, 9000, 1,
+ 11000, 12000, 13000, 14000,
+ 15000, 16000, 17000, 18000,
+ 19000, 2, 21000, 22000,
+ /* 0x20 */
+ 23000, 24000, 25000,
+};
+
+const struct rohm_dvs_config buck1_dvs = {
+ .level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_SNVS |
+ ROHM_DVS_LEVEL_SUSPEND | ROHM_DVS_LEVEL_LPSR,
+ .run_reg= BD71815_REG_BUCK1_VOLT_H,
+ .run_mask = BD71815_VOLT_MASK,
+ .run_on_mask= BD71815_BUCK_RUN_ON,
+ .snvs_on_mask = BD71815_BUCK_SNVS_ON,
+ .suspend_reg= BD71815_REG_BUCK1_VOLT_L,
+ .suspend_mask = BD71815_VOLT_MASK,
+ .suspend_on_mask= BD71815_BUCK_SUSP_ON,
+ .lpsr_reg = BD71815_REG_BUCK1_VOLT_L,
+ .lpsr_mask = BD71815_VOLT_MASK,
+ .lpsr_on_mask = BD71815_BUCK_LPSR_ON,
+};
+
+const struct rohm_dvs_config buck2_dvs = {
+ .level_map = ROHM_DVS_LEVEL_RUN | ROHM_DVS_LEVEL_SNVS |
+ ROHM_DVS_LEVEL_SUSPEND | ROHM_DVS_LEVEL_LPSR,
+ .run_reg= BD71815_REG_BUCK2_VOLT_H,
+ .run_mask = BD71815_VOLT_MASK,
+ .run_on_mask= BD71815_BUCK_RUN_ON,
+ .snvs_on_mask =
[PATCH v2 12/17] regulator: rohm-regulator: linear voltage support
The helper for obtaining HW-state based DVS voltage levels currently only
works for regulators using linear-ranges. Extend support to regulators with
simple linear mappings and add also proper error path if pickable-ranges
regulators call this.
Signed-off-by: Matti Vaittinen
---
Changes since v1:
- moved SNVS level adding to own patch
drivers/regulator/rohm-regulator.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/rohm-regulator.c
b/drivers/regulator/rohm-regulator.c
index 5c558b153d55..63aabb8c7786 100644
--- a/drivers/regulator/rohm-regulator.c
+++ b/drivers/regulator/rohm-regulator.c
@@ -22,13 +22,26 @@ static int set_dvs_level(const struct regulator_desc *desc,
return ret;
return 0;
}
-
+ /* If voltage is set to 0 => disable */
if (uv == 0) {
if (omask)
return regmap_update_bits(regmap, oreg, omask, 0);
}
+ /* Some setups don't allow setting own voltage but do allow enabling */
+ if (!mask) {
+ if (omask)
+ return regmap_update_bits(regmap, oreg, omask, omask);
+
+ return -EINVAL;
+ }
for (i = 0; i < desc->n_voltages; i++) {
- ret = regulator_desc_list_voltage_linear_range(desc, i);
+ /* NOTE to next hacker - Does not support pickable ranges */
+ if (desc->linear_range_selectors)
+ return -EINVAL;
+ if (desc->n_linear_ranges)
+ ret = regulator_desc_list_voltage_linear_range(desc, i);
+ else
+ ret = regulator_desc_list_voltage_linear(desc, i);
if (ret < 0)
continue;
if (ret == uv) {
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
[PATCH v2 13/17] regulator: rohm-regulator: Support SNVS HW state.
The ROHM BD71815 supports setting voltage levels/regulator status
for HW-states "RUN", "SUSPEND", "LPSR" and "SNVS". Add DT parsing
helper also for SNVS state.
Signed-off-by: Matti Vaittinen
---
Changes since v1:
New patch (split patch).
drivers/regulator/rohm-regulator.c | 6 ++
include/linux/mfd/rohm-generic.h | 6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/rohm-regulator.c
b/drivers/regulator/rohm-regulator.c
index 63aabb8c7786..6e0d9c08ec1c 100644
--- a/drivers/regulator/rohm-regulator.c
+++ b/drivers/regulator/rohm-regulator.c
@@ -95,6 +95,12 @@ int rohm_regulator_set_dvs_levels(const struct
rohm_dvs_config *dvs,
mask = dvs->lpsr_mask;
omask = dvs->lpsr_on_mask;
break;
+ case ROHM_DVS_LEVEL_SNVS:
+ prop = "rohm,dvs-snvs-voltage";
+ reg = dvs->snvs_reg;
+ mask = dvs->snvs_mask;
+ omask = dvs->snvs_on_mask;
+ break;
default:
return -EINVAL;
}
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index bbf07a49823c..baed47fd0ff3 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -25,7 +25,8 @@ struct rohm_regmap_dev {
#define ROHM_DVS_LEVEL_IDLEBIT(1)
#define ROHM_DVS_LEVEL_SUSPEND BIT(2)
#define ROHM_DVS_LEVEL_LPSRBIT(3)
-#define ROHM_DVS_LEVEL_VALID_AMOUNT4
+#define ROHM_DVS_LEVEL_SNVSBIT(4)
+#define ROHM_DVS_LEVEL_VALID_AMOUNT5
#define ROHM_DVS_LEVEL_UNKNOWN 0
/**
@@ -64,6 +65,9 @@ struct rohm_dvs_config {
unsigned int lpsr_reg;
unsigned int lpsr_mask;
unsigned int lpsr_on_mask;
+ unsigned int snvs_reg;
+ unsigned int snvs_mask;
+ unsigned int snvs_on_mask;
};
#if IS_ENABLED(CONFIG_REGULATOR_ROHM)
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
[PATCH v2 11/17] regulator: helpers: Export helper voltage listing
Some drivers need to translate voltage values to selectors prior regulator
registration. Currently a regulator_desc based list_voltages helper is only
exported for regulators using the linear_ranges. Export similar helper also
for regulators using simple linear mapping.
Signed-off-by: Matti Vaittinen
---
No changes since v1
drivers/regulator/helpers.c | 36 +---
include/linux/regulator/driver.h | 2 ++
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/helpers.c b/drivers/regulator/helpers.c
index f42b394a0c46..3e19ecbf7267 100644
--- a/drivers/regulator/helpers.c
+++ b/drivers/regulator/helpers.c
@@ -508,6 +508,33 @@ int regulator_map_voltage_pickable_linear_range(struct
regulator_dev *rdev,
}
EXPORT_SYMBOL_GPL(regulator_map_voltage_pickable_linear_range);
+/**
+ * regulator_desc_list_voltage_linear - List voltages with simple calculation
+ *
+ * @desc: Regulator desc for regulator which volatges are to be listed
+ * @selector: Selector to convert into a voltage
+ *
+ * Regulators with a simple linear mapping between voltages and
+ * selectors can set min_uV and uV_step in the regulator descriptor
+ * and then use this function prior regulator registration to list
+ * the voltages. This is useful when voltages need to be listed during
+ * device-tree parsing.
+ */
+int regulator_desc_list_voltage_linear(const struct regulator_desc *desc,
+ unsigned int selector)
+{
+ if (selector >= desc->n_voltages)
+ return -EINVAL;
+
+ if (selector < desc->linear_min_sel)
+ return 0;
+
+ selector -= desc->linear_min_sel;
+
+ return desc->min_uV + (desc->uV_step * selector);
+}
+EXPORT_SYMBOL_GPL(regulator_desc_list_voltage_linear);
+
/**
* regulator_list_voltage_linear - List voltages with simple calculation
*
@@ -521,14 +548,7 @@
EXPORT_SYMBOL_GPL(regulator_map_voltage_pickable_linear_range);
int regulator_list_voltage_linear(struct regulator_dev *rdev,
unsigned int selector)
{
- if (selector >= rdev->desc->n_voltages)
- return -EINVAL;
- if (selector < rdev->desc->linear_min_sel)
- return 0;
-
- selector -= rdev->desc->linear_min_sel;
-
- return rdev->desc->min_uV + (rdev->desc->uV_step * selector);
+ return regulator_desc_list_voltage_linear(rdev->desc, selector);
}
EXPORT_SYMBOL_GPL(regulator_list_voltage_linear);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index d7c77ee370f3..39a540111645 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -543,4 +543,6 @@ void *regulator_get_init_drvdata(struct regulator_init_data
*reg_init_data);
int regulator_desc_list_voltage_linear_range(const struct regulator_desc *desc,
unsigned int selector);
+int regulator_desc_list_voltage_linear(const struct regulator_desc *desc,
+ unsigned int selector);
#endif
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Re: linux-next: build warnings after merge of the jc_docs tree
Hi all, On Tue, 19 Jan 2021 17:13:03 +1100 Stephen Rothwell wrote: > > Hi all, > > After merging the jc_docs tree, today's linux-next build (KCONFIG_NAME) > produced these warnings: > Also, these: tools/testing/selftests/kselftest_harness.h:82: warning: wrong kernel-doc identifier on line: * TH_LOG(fmt, ...) tools/testing/selftests/kselftest_harness.h:116: warning: wrong kernel-doc identifier on line: * SKIP(statement, fmt, ...) tools/testing/selftests/kselftest_harness.h:139: warning: wrong kernel-doc identifier on line: * TEST(test_name) - Defines the test function and creates the registration tools/testing/selftests/kselftest_harness.h:158: warning: wrong kernel-doc identifier on line: * TEST_SIGNAL(test_name, signal) tools/testing/selftests/kselftest_harness.h:198: warning: wrong kernel-doc identifier on line: * FIXTURE_DATA(datatype_name) - Wraps the struct name so we have one less tools/testing/selftests/kselftest_harness.h:215: warning: wrong kernel-doc identifier on line: * FIXTURE(fixture_name) - Called once per fixture to setup the data and tools/testing/selftests/kselftest_harness.h:242: warning: wrong kernel-doc identifier on line: * FIXTURE_SETUP(fixture_name) - Prepares the setup function for the fixture. tools/testing/selftests/kselftest_harness.h:268: warning: wrong kernel-doc identifier on line: * FIXTURE_TEARDOWN(fixture_name) tools/testing/selftests/kselftest_harness.h:289: warning: wrong kernel-doc identifier on line: * FIXTURE_VARIANT(fixture_name) - Optionally called once per fixture tools/testing/selftests/kselftest_harness.h:308: warning: wrong kernel-doc identifier on line: * FIXTURE_VARIANT_ADD(fixture_name, variant_name) - Called once per fixture tools/testing/selftests/kselftest_harness.h:342: warning: wrong kernel-doc identifier on line: * TEST_F(fixture_name, test_name) - Emits test registration and helpers for include/linux/seqlock.h:829: warning: wrong kernel-doc identifier on line: * DEFINE_SEQLOCK(sl) - Define a statically allocated seqlock_t tools/testing/selftests/kselftest_harness.h:82: warning: wrong kernel-doc identifier on line: * TH_LOG(fmt, ...) tools/testing/selftests/kselftest_harness.h:116: warning: wrong kernel-doc identifier on line: * SKIP(statement, fmt, ...) tools/testing/selftests/kselftest_harness.h:139: warning: wrong kernel-doc identifier on line: * TEST(test_name) - Defines the test function and creates the registration tools/testing/selftests/kselftest_harness.h:158: warning: wrong kernel-doc identifier on line: * TEST_SIGNAL(test_name, signal) tools/testing/selftests/kselftest_harness.h:198: warning: wrong kernel-doc identifier on line: * FIXTURE_DATA(datatype_name) - Wraps the struct name so we have one less tools/testing/selftests/kselftest_harness.h:215: warning: wrong kernel-doc identifier on line: * FIXTURE(fixture_name) - Called once per fixture to setup the data and tools/testing/selftests/kselftest_harness.h:242: warning: wrong kernel-doc identifier on line: * FIXTURE_SETUP(fixture_name) - Prepares the setup function for the fixture. tools/testing/selftests/kselftest_harness.h:268: warning: wrong kernel-doc identifier on line: * FIXTURE_TEARDOWN(fixture_name) tools/testing/selftests/kselftest_harness.h:289: warning: wrong kernel-doc identifier on line: * FIXTURE_VARIANT(fixture_name) - Optionally called once per fixture tools/testing/selftests/kselftest_harness.h:308: warning: wrong kernel-doc identifier on line: * FIXTURE_VARIANT_ADD(fixture_name, variant_name) - Called once per fixture tools/testing/selftests/kselftest_harness.h:342: warning: wrong kernel-doc identifier on line: * TEST_F(fixture_name, test_name) - Emits test registration and helpers for tools/testing/selftests/kselftest_harness.h:82: warning: wrong kernel-doc identifier on line: * TH_LOG(fmt, ...) tools/testing/selftests/kselftest_harness.h:116: warning: wrong kernel-doc identifier on line: * SKIP(statement, fmt, ...) tools/testing/selftests/kselftest_harness.h:139: warning: wrong kernel-doc identifier on line: * TEST(test_name) - Defines the test function and creates the registration tools/testing/selftests/kselftest_harness.h:158: warning: wrong kernel-doc identifier on line: * TEST_SIGNAL(test_name, signal) tools/testing/selftests/kselftest_harness.h:198: warning: wrong kernel-doc identifier on line: * FIXTURE_DATA(datatype_name) - Wraps the struct name so we have one less tools/testing/selftests/kselftest_harness.h:215: warning: wrong kernel-doc identifier on line: * FIXTURE(fixture_name) - Called once per fixture to setup the data and tools/testing/selftests/kselftest_harness.h:242: warning: wrong kernel-doc identifier on line: * FIXTURE_SETUP(fixture_name) - Prepares the setup function for the fixture. tools/testing/selftests/kselftest_harness.h:268: warning: wrong kernel-doc identifier on line: * FIXTURE_TEARDOWN(fixture_name) tools/testing/selftests/kselftest_harness.h:289: warning: wrong
[PATCH v2 10/17] gpio: support ROHM BD71815 GPOs
Support GPO(s) found from ROHM BD71815 power management IC. The IC has two
GPO pins but only one is properly documented in data-sheet. The driver
exposes by default only the documented GPO. The second GPO is connected to
E5 pin and is marked as GND in data-sheet. Control for this undocumented
pin can be enabled using a special DT property.
This driver is derived from work by Peter Yang
although not so much of original is left.
Signed-off-by: Matti Vaittinen
---
Changes since v1:
- removed unneeded headers
- clarified dev/parent->dev usage
- removed forgotten #define DEBUG
drivers/gpio/Kconfig| 10 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-bd71815.c | 171
3 files changed, 182 insertions(+)
create mode 100644 drivers/gpio/gpio-bd71815.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c70f46e80a3b..fd7283af858d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1096,6 +1096,16 @@ config GPIO_BD70528
This driver can also be built as a module. If so, the module
will be called gpio-bd70528.
+config GPIO_BD71815
+ tristate "ROHM BD71815 PMIC GPIO support"
+ depends on MFD_ROHM_BD71828
+ help
+ Support for GPO(s) on ROHM BD71815 PMIC. There are two GPOs
+ available on the ROHM PMIC.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-bd71815.
+
config GPIO_BD71828
tristate "ROHM BD71828 GPIO support"
depends on MFD_ROHM_BD71828
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 35e3b6026665..86bb680522a6 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
obj-$(CONFIG_GPIO_BCM_KONA)+= gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BCM_XGS_IPROC) += gpio-xgs-iproc.o
obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
+obj-$(CONFIG_GPIO_BD71815) += gpio-bd71815.o
obj-$(CONFIG_GPIO_BD71828) += gpio-bd71828.o
obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
diff --git a/drivers/gpio/gpio-bd71815.c b/drivers/gpio/gpio-bd71815.c
new file mode 100644
index ..664de5f69bf1
--- /dev/null
+++ b/drivers/gpio/gpio-bd71815.c
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Support to GPOs on ROHM BD71815
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+/* For the BD71815 register definitions */
+#include
+
+struct bd71815_gpio {
+ struct gpio_chip chip;
+ struct device *dev;
+ struct regmap *regmap;
+ /*
+* Sigh. The BD71815 and BD71817 were originally designed to support two
+* GPO pins. At some point it was noticed the second GPO pin which is
+* the E5 pin located at the center of IC is hard to use on PCB (due to
+* the location). It was decided to not promote this second GPO and pin
+* is marked as GND on the data-sheet. The functionality is still there
+* though! I guess driving GPO connected to ground is a bad idea. Thus
+* we do not support it by default. OTOH - the original driver written
+* by colleagues at Embest did support controlling this second GPO. It
+* is thus possible this is used in some of the products.
+*
+* This driver does not by default support configuring this second GPO
+* but allows using it by providing the DT property
+* "rohm,enable-hidden-gpo".
+*/
+ bool e5_pin_is_gpo;
+};
+
+static int bd71815gpo_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct bd71815_gpio *bd71815 = gpiochip_get_data(chip);
+ int ret = 0;
+ int val;
+
+ ret = regmap_read(bd71815->regmap, BD71815_REG_GPO, );
+ if (ret)
+ return ret;
+
+ return (val >> offset) & 1;
+}
+
+static void bd71815gpo_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ struct bd71815_gpio *bd71815 = gpiochip_get_data(chip);
+ int ret, val, mask;
+
+ if (!bd71815->e5_pin_is_gpo && offset)
+ return;
+
+ mask = BIT(offset);
+ val = value ? mask : 0;
+ ret = regmap_update_bits(bd71815->regmap, BD71815_REG_GPO, mask, val);
+ if (ret)
+ dev_warn(bd71815->dev, "failed to toggle GPO\n");
+}
+
+static int bd71815_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ struct bd71815_gpio *bdgpio = gpiochip_get_data(chip);
+
+ if (!bdgpio->e5_pin_is_gpo && offset)
+ return -EOPNOTSUPP;
+
+ switch (pinconf_to_config_param(config)) {
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ return regmap_update_bits(bdgpio->regmap,
+
[PATCH v2 08/17] mfd: Add ROHM BD71815 ID
Add chip ID for ROHM BD71815 and PMIC so that drivers can identify
this IC.
Signed-off-by: Matti Vaittinen
---
No changes since v1.
include/linux/mfd/rohm-generic.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index 2b85b9deb03a..bbf07a49823c 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -12,6 +12,7 @@ enum rohm_chip_type {
ROHM_CHIP_TYPE_BD71847,
ROHM_CHIP_TYPE_BD70528,
ROHM_CHIP_TYPE_BD71828,
+ ROHM_CHIP_TYPE_BD71815,
ROHM_CHIP_TYPE_AMOUNT
};
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
[PATCH v2 07/17] dt_bindings: mfd: Add ROHM BD71815 PMIC
Document DT bindings for ROHM BD71815.
BD71815 is a single-chip power management IC mainly for battery-powered
portable devices. The IC integrates 5 bucks, 7 LDOs, a boost driver for
LED, a battery charger with a Coulomb counter, a real-time clock, a 32kHz
clock and two general-purpose outputs although only one is documented by
the data-sheet.
Signed-off-by: Matti Vaittinen
---
Changes since v1:
- fixed patch ordering to meet ref dependencies
- added missing blank lines
- clkout-mode changed from string to tristated (uint)
- added default for rsense resistor
.../bindings/mfd/rohm,bd71815-pmic.yaml | 202 ++
1 file changed, 202 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
new file mode 100644
index ..b52b8585d48d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml
@@ -0,0 +1,202 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/rohm,bd71815-pmic.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROHM BD71815 Power Management Integrated Circuit bindings
+
+maintainers:
+ - Matti Vaittinen
+
+description: |
+ BD71815AGW is a single-chip power management ICs for battery-powered
+ portable devices. It integrates 5 buck converters, 8 LDOs, a boost driver
+ for LED and a 500 mA single-cell linear charger. Also included is a Coulomb
+ counter, a real-time clock (RTC), and a 32.768 kHz clock gate and two GPOs.
+
+properties:
+ compatible:
+const: rohm,bd71815
+
+ reg:
+description:
+ I2C slave address.
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+const: 2
+description: |
+ The first cell is the pin number and the second cell is used to specify
+ flags. See ../gpio/gpio.txt for more information.
+
+ clocks:
+maxItems: 1
+
+ "#clock-cells":
+const: 0
+
+ clock-output-names:
+const: bd71815-32k-out
+
+ rohm,clkout-open-drain:
+description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
+$ref: "/schemas/types.yaml#/definitions/uint32"
+minimum: 0
+maximum: 1
+
+ rohm,charger-sense-resistor-ohms:
+minimum: 1000
+maximum: 5000
+description: |
+ BD71827 and BD71828 have SAR ADC for measuring charging currents.
+ External sense resistor (RSENSE in data sheet) should be used. If
+ something other but 30MOhm resistor is used the resistance value
+ should be given
+ here in Ohms.
+default: 3000
+
+ regulators:
+$ref: ../regulator/rohm,bd71815-regulator.yaml
+description:
+ List of child nodes that specify the regulators.
+
+ gpio-reserved-ranges:
+description: |
+ Usage of BD71828 GPIO pins can be changed via OTP. This property can be
+ used to mark the pins which should not be configured for GPIO. Please see
+ the ../gpio/gpio.txt for more information.
+
+ rohm,enable-hidden-gpo:
+description: |
+ The BD71815 has undocumented GPO at pin E5. Pin is marked as GND at the
+ data-sheet as it's location in the middle of GND pins makes it hard to
+ use on PCB. If your board has managed to use this pin you can enable the
+ second GPO by defining this property. Dont enable this if you are unsure
+ about how the E5 pin is connected on your board.
+type: boolean
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - "#clock-cells"
+ - regulators
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+pmic: pmic@4b {
+compatible = "rohm,bd71815";
+reg = <0x4b>;
+
+interrupt-parent = <>;
+interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+clocks = < 0>;
+#clock-cells = <0>;
+clock-output-names = "bd71815-32k-out";
+
+gpio-controller;
+#gpio-cells = <2>;
+
+rohm,charger-sense-resistor-ohms = <1000>;
+
+regulators {
+buck1: buck1 {
+regulator-name = "buck1";
+regulator-min-microvolt = <80>;
+regulator-max-microvolt = <200>;
+regulator-always-on;
+regulator-ramp-delay = <1250>;
+rohm,dvs-run-voltage = <115>;
+rohm,dvs-suspend-voltage = <95>;
+};
+buck2: buck2 {
+regulator-name = "buck2";
+regulator-min-microvolt = <80>;
+regulator-max-microvolt = <200>;
+
[PATCH v2] mm: page_counter: relayout structure to reduce false sharing
When checking a memory cgroup related performance regression [1],
from the perf c2c profiling data, we found high false sharing for
accessing 'usage' and 'parent'.
On 64 bit system, the 'usage' and 'parent' are close to each other,
and easy to be in one cacheline (for cacheline size == 64+ B). 'usage'
is usally written, while 'parent' is usually read as the cgroup's
hierarchical counting nature.
So move the 'parent' to the end of the structure to make sure they
are in different cache lines.
Following are some performance data with the patch, against
v5.11-rc1. [ In the data, A means a platform with 2 sockets 48C/96T,
B is a platform of 4 sockests 72C/144T, and if a %stddev will be
shown bigger than 2%, P100/P50 means number of test tasks equals
to 100%/50% of nr_cpu]
will-it-scale/malloc1
-
v5.11-rc1v5.11-rc1+patch
A-P100 15782 ± 2% -0.1% 15765 ± 3%
will-it-scale.per_process_ops
A-P5021511+8.9% 23432
will-it-scale.per_process_ops
B-P1009155+2.2% 9357
will-it-scale.per_process_ops
B-P5010967+7.1% 11751 ± 2%
will-it-scale.per_process_ops
will-it-scale/pagefault2
v5.11-rc1v5.11-rc1+patch
A-P100 79028+3.0% 81411
will-it-scale.per_process_ops
A-P50 183960 ± 2% +4.4% 192078 ± 2%
will-it-scale.per_process_ops
B-P100 85966+9.9% 94467 ± 3%
will-it-scale.per_process_ops
B-P50 198195+9.8% 217526
will-it-scale.per_process_ops
fio (4k/1M is block size)
-
v5.11-rc1v5.11-rc1+patch
A-P50-r-4k 16881 ± 2%+1.2% 17081 ± 2% fio.read_bw_MBps
A-P50-w-4k 3931 +4.5% 4111 ± 2% fio.write_bw_MBps
A-P50-r-1M 15178 -0.2% 15154fio.read_bw_MBps
A-P50-w-1M 3924 +0.1% 3929fio.write_bw_MBps
[1].https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/
Signed-off-by: Feng Tang
Reviewed-by: Roman Gushchin
Cc: Johannes Weiner
Cc: Michal Hocko
---
Changelogs:
v2:
* Adjust the format of performance data to be more readable,
as suggested by Michal Hocko
include/linux/page_counter.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
index 85bd413..6795913 100644
--- a/include/linux/page_counter.h
+++ b/include/linux/page_counter.h
@@ -12,7 +12,6 @@ struct page_counter {
unsigned long low;
unsigned long high;
unsigned long max;
- struct page_counter *parent;
/* effective memory.min and memory.min usage tracking */
unsigned long emin;
@@ -27,6 +26,14 @@ struct page_counter {
/* legacy */
unsigned long watermark;
unsigned long failcnt;
+
+ /*
+* 'parent' is placed here to be far from 'usage' to reduce
+* cache false sharing, as 'usage' is written mostly while
+* parent is frequently read for cgroup's hierarchical
+* counting nature.
+*/
+ struct page_counter *parent;
};
#if BITS_PER_LONG == 32
--
2.7.4
Re: [PATCH] USB: gadget: udc: Process disconnect synchronously
Davidlohr Bueso writes: > As the comment in usb_disconnect() hints, do not defer the > disconnect processing, and instead just do it directly in > the irq handler. This allows the driver to avoid using a > nowadays deprecated tasklet. > > Signed-off-by: Davidlohr Bueso You may have to deal with VBUS valid, but for now this is good: Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
[PATCH v2 02/17] rtc: bd70528: Do not require parent data
The ROHM BD71828 and BD71815 RTC drivers only need the regmap
pointer from parent. Regmap can be obtained via dev_get_regmap()
so do not require parent to populate driver data for that.
BD70528 on the other hand requires parent data to access the
watchdog so leave the parent data for BD70528 here for now.
Signed-off-by: Matti Vaittinen
---
Please note that this same change has been sent individually:
https://lore.kernel.org/lkml/20210105152350.GA3714833@localhost.localdomain/
It is present in this series only because some patches depend on it.
drivers/rtc/rtc-bd70528.c | 67 ++-
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
index 17cb67f5bf6e..fb4476bb5ab6 100644
--- a/drivers/rtc/rtc-bd70528.c
+++ b/drivers/rtc/rtc-bd70528.c
@@ -52,6 +52,7 @@ struct bd70528_rtc_alm {
struct bd70528_rtc {
struct rohm_regmap_dev *parent;
+ struct regmap *regmap;
struct device *dev;
u8 reg_time_start;
bool has_rtc_timers;
@@ -234,9 +235,8 @@ static int bd71828_set_alarm(struct device *dev, struct
rtc_wkalrm *a)
int ret;
struct bd71828_rtc_alm alm;
struct bd70528_rtc *r = dev_get_drvdata(dev);
- struct rohm_regmap_dev *parent = r->parent;
- ret = regmap_bulk_read(parent->regmap, BD71828_REG_RTC_ALM_START,
+ ret = regmap_bulk_read(r->regmap, BD71828_REG_RTC_ALM_START,
, sizeof(alm));
if (ret) {
dev_err(dev, "Failed to read alarm regs\n");
@@ -250,7 +250,7 @@ static int bd71828_set_alarm(struct device *dev, struct
rtc_wkalrm *a)
else
alm.alm_mask |= BD70528_MASK_ALM_EN;
- ret = regmap_bulk_write(parent->regmap, BD71828_REG_RTC_ALM_START,
+ ret = regmap_bulk_write(r->regmap, BD71828_REG_RTC_ALM_START,
, sizeof(alm));
if (ret)
dev_err(dev, "Failed to set alarm time\n");
@@ -265,17 +265,16 @@ static int bd70528_set_alarm(struct device *dev, struct
rtc_wkalrm *a)
struct bd70528_rtc_alm alm;
int ret;
struct bd70528_rtc *r = dev_get_drvdata(dev);
- struct rohm_regmap_dev *parent = r->parent;
- ret = regmap_bulk_read(parent->regmap, BD70528_REG_RTC_WAKE_START,
- , sizeof(wake));
+ ret = regmap_bulk_read(r->regmap, BD70528_REG_RTC_WAKE_START, ,
+ sizeof(wake));
if (ret) {
dev_err(dev, "Failed to read wake regs\n");
return ret;
}
- ret = regmap_bulk_read(parent->regmap, BD70528_REG_RTC_ALM_START,
- , sizeof(alm));
+ ret = regmap_bulk_read(r->regmap, BD70528_REG_RTC_ALM_START, ,
+ sizeof(alm));
if (ret) {
dev_err(dev, "Failed to read alarm regs\n");
return ret;
@@ -292,15 +291,14 @@ static int bd70528_set_alarm(struct device *dev, struct
rtc_wkalrm *a)
wake.ctrl &= ~BD70528_MASK_WAKE_EN;
}
- ret = regmap_bulk_write(parent->regmap,
- BD70528_REG_RTC_WAKE_START, ,
+ ret = regmap_bulk_write(r->regmap, BD70528_REG_RTC_WAKE_START, ,
sizeof(wake));
if (ret) {
dev_err(dev, "Failed to set wake time\n");
return ret;
}
- ret = regmap_bulk_write(parent->regmap, BD70528_REG_RTC_ALM_START,
- , sizeof(alm));
+ ret = regmap_bulk_write(r->regmap, BD70528_REG_RTC_ALM_START, ,
+ sizeof(alm));
if (ret)
dev_err(dev, "Failed to set alarm time\n");
@@ -312,9 +310,8 @@ static int bd71828_read_alarm(struct device *dev, struct
rtc_wkalrm *a)
int ret;
struct bd71828_rtc_alm alm;
struct bd70528_rtc *r = dev_get_drvdata(dev);
- struct rohm_regmap_dev *parent = r->parent;
- ret = regmap_bulk_read(parent->regmap, BD71828_REG_RTC_ALM_START,
+ ret = regmap_bulk_read(r->regmap, BD71828_REG_RTC_ALM_START,
, sizeof(alm));
if (ret) {
dev_err(dev, "Failed to read alarm regs\n");
@@ -336,10 +333,9 @@ static int bd70528_read_alarm(struct device *dev, struct
rtc_wkalrm *a)
struct bd70528_rtc_alm alm;
int ret;
struct bd70528_rtc *r = dev_get_drvdata(dev);
- struct rohm_regmap_dev *parent = r->parent;
- ret = regmap_bulk_read(parent->regmap, BD70528_REG_RTC_ALM_START,
- , sizeof(alm));
+ ret = regmap_bulk_read(r->regmap, BD70528_REG_RTC_ALM_START, ,
+ sizeof(alm));
if (ret) {
dev_err(dev, "Failed to read alarm regs\n");
return ret;
@@ -360,14 +356,12 @@ static int bd70528_set_time_locked(struct
[PATCH v2 03/17] clk: BD718x7: Do not depend on parent driver data
The bd718x7 only needs a regmap from parent device. This can be
obtained by call to dev_get_regmap. Do not require parent to
populate the driver data for this.
Signed-off-by: Matti Vaittinen
---
Please note that this same change has been sent individually:
https://lore.kernel.org/lkml/20210105123028.GA3409663@localhost.localdomain/
It is present in this series only because some patches depend on it.
drivers/clk/clk-bd718x7.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index b52e8d6f660c..17d90e09f1c0 100644
--- a/drivers/clk/clk-bd718x7.c
+++ b/drivers/clk/clk-bd718x7.c
@@ -31,12 +31,12 @@ struct bd718xx_clk {
u8 reg;
u8 mask;
struct platform_device *pdev;
- struct rohm_regmap_dev *mfd;
+ struct regmap *regmap;
};
static int bd71837_clk_set(struct bd718xx_clk *c, unsigned int status)
{
- return regmap_update_bits(c->mfd->regmap, c->reg, c->mask, status);
+ return regmap_update_bits(c->regmap, c->reg, c->mask, status);
}
static void bd71837_clk_disable(struct clk_hw *hw)
@@ -62,7 +62,7 @@ static int bd71837_clk_is_enabled(struct clk_hw *hw)
int rval;
struct bd718xx_clk *c = container_of(hw, struct bd718xx_clk, hw);
- rval = regmap_read(c->mfd->regmap, c->reg, );
+ rval = regmap_read(c->regmap, c->reg, );
if (rval)
return rval;
@@ -82,7 +82,6 @@ static int bd71837_clk_probe(struct platform_device *pdev)
int rval = -ENOMEM;
const char *parent_clk;
struct device *parent = pdev->dev.parent;
- struct rohm_regmap_dev *mfd = dev_get_drvdata(parent);
struct clk_init_data init = {
.name = "bd718xx-32k-out",
.ops = _clk_ops,
@@ -93,6 +92,10 @@ static int bd71837_clk_probe(struct platform_device *pdev)
if (!c)
return -ENOMEM;
+ c->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!c->regmap)
+ return -ENODEV;
+
init.num_parents = 1;
parent_clk = of_clk_get_parent_name(parent->of_node, 0);
@@ -119,7 +122,6 @@ static int bd71837_clk_probe(struct platform_device *pdev)
dev_err(>dev, "Unknown clk chip\n");
return -EINVAL;
}
- c->mfd = mfd;
c->pdev = pdev;
c->hw.init =
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
[PATCH v2 04/17] mfd: bd718x7: simplify by cleaning unnecessary device data
Most ROHM PMIC sub-devices only use the regmap pointer from
parent device. They can obtain this by dev_get_regamap so in
most cases the MFD device does not need to allocate and populate
the driver data. Simplify drivers by removing this.
The BD70528 still needs the access to watchdog mutex so keep
rohm_regmap_dev in use on BD70528 RTC and WDG drivers for now.
Signed-off-by: Matti Vaittinen
---
No changes since v1
drivers/mfd/rohm-bd718x7.c | 43
include/linux/mfd/rohm-bd718x7.h | 13 --
2 files changed, 16 insertions(+), 40 deletions(-)
diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
index c32c1b6c98fa..bfd81f78beae 100644
--- a/drivers/mfd/rohm-bd718x7.c
+++ b/drivers/mfd/rohm-bd718x7.c
@@ -91,9 +91,9 @@ static const struct regmap_config bd718xx_regmap_config = {
.cache_type = REGCACHE_RBTREE,
};
-static int bd718xx_init_press_duration(struct bd718xx *bd718xx)
+static int bd718xx_init_press_duration(struct regmap *regmap,
+ struct device *dev)
{
- struct device* dev = bd718xx->chip.dev;
u32 short_press_ms, long_press_ms;
u32 short_press_value, long_press_value;
int ret;
@@ -102,8 +102,7 @@ static int bd718xx_init_press_duration(struct bd718xx
*bd718xx)
_press_ms);
if (!ret) {
short_press_value = min(15u, (short_press_ms + 250) / 500);
- ret = regmap_update_bits(bd718xx->chip.regmap,
-BD718XX_REG_PWRONCONFIG0,
+ ret = regmap_update_bits(regmap, BD718XX_REG_PWRONCONFIG0,
BD718XX_PWRBTN_PRESS_DURATION_MASK,
short_press_value);
if (ret) {
@@ -116,8 +115,7 @@ static int bd718xx_init_press_duration(struct bd718xx
*bd718xx)
_press_ms);
if (!ret) {
long_press_value = min(15u, (long_press_ms + 500) / 1000);
- ret = regmap_update_bits(bd718xx->chip.regmap,
-BD718XX_REG_PWRONCONFIG1,
+ ret = regmap_update_bits(regmap, BD718XX_REG_PWRONCONFIG1,
BD718XX_PWRBTN_PRESS_DURATION_MASK,
long_press_value);
if (ret) {
@@ -132,7 +130,8 @@ static int bd718xx_init_press_duration(struct bd718xx
*bd718xx)
static int bd718xx_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
- struct bd718xx *bd718xx;
+ struct regmap *regmap;
+ struct regmap_irq_chip_data *irq_data;
int ret;
unsigned int chip_type;
struct mfd_cell *mfd;
@@ -142,13 +141,6 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
dev_err(>dev, "No IRQ configured\n");
return -EINVAL;
}
-
- bd718xx = devm_kzalloc(>dev, sizeof(struct bd718xx), GFP_KERNEL);
-
- if (!bd718xx)
- return -ENOMEM;
-
- bd718xx->chip_irq = i2c->irq;
chip_type = (unsigned int)(uintptr_t)
of_device_get_match_data(>dev);
switch (chip_type) {
@@ -164,29 +156,26 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
dev_err(>dev, "Unknown device type");
return -EINVAL;
}
- bd718xx->chip.dev = >dev;
- dev_set_drvdata(>dev, bd718xx);
- bd718xx->chip.regmap = devm_regmap_init_i2c(i2c,
- _regmap_config);
- if (IS_ERR(bd718xx->chip.regmap)) {
+ regmap = devm_regmap_init_i2c(i2c, _regmap_config);
+ if (IS_ERR(regmap)) {
dev_err(>dev, "regmap initialization failed\n");
- return PTR_ERR(bd718xx->chip.regmap);
+ return PTR_ERR(regmap);
}
- ret = devm_regmap_add_irq_chip(>dev, bd718xx->chip.regmap,
- bd718xx->chip_irq, IRQF_ONESHOT, 0,
- _irq_chip, >irq_data);
+ ret = devm_regmap_add_irq_chip(>dev, regmap, i2c->irq,
+ IRQF_ONESHOT, 0, _irq_chip,
+ _data);
if (ret) {
dev_err(>dev, "Failed to add irq_chip\n");
return ret;
}
- ret = bd718xx_init_press_duration(bd718xx);
+ ret = bd718xx_init_press_duration(regmap, >dev);
if (ret)
return ret;
- ret = regmap_irq_get_virq(bd718xx->irq_data, BD718XX_INT_PWRBTN_S);
+ ret = regmap_irq_get_virq(irq_data, BD718XX_INT_PWRBTN_S);
if (ret < 0) {
dev_err(>dev, "Failed to get the IRQ\n");
@@ -195,9 +184,9 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
button.irq = ret;
- ret =
[PATCH v2 06/17] dt_bindings: regulator: Add ROHM BD71815 PMIC regulators
Add binding documentation for regulators on ROHM BD71815 PMIC. 5 bucks, 7 LDOs and a boost for LED. Signed-off-by: Matti Vaittinen --- Changes since v1: - Changed patch order to fix ref dependecy - Added missing schema for nodes wled, ldodvref, ldolpsr .../regulator/rohm,bd71815-regulator.yaml | 116 ++ 1 file changed, 116 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml new file mode 100644 index ..7d0adb74a396 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/rohm,bd71815-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD71815 Power Management Integrated Circuit regulators + +maintainers: + - Matti Vaittinen + +description: | + This module is part of the ROHM BD718215 MFD device. For more details + see Documentation/devicetree/bindings/mfd/rohm,bd71815-pmic.yaml. + + The regulator controller is represented as a sub-node of the PMIC node + on the device tree. + + The valid names for BD71815 regulator nodes are + buck1, buck2, buck3, buck4, buck5, + ldo1, ldo2, ldo3, ldo4, ldo5, + ldodvref, ldolpsr, wled + +properties: + wled: +type: object +description: + properties for wled regulator +$ref: regulator.yaml# + +properties: + regulator-name: +const: wled + +patternProperties: + "^((ldo|buck)[1-5]|ldolpsr|ldodvref)$": +type: object +description: + Properties for single LDO/BUCK regulator. +$ref: regulator.yaml# + +properties: + regulator-name: +pattern: "^((ldo|buck)[1-5]|ldolpsr|ldodvref)$" +description: + should be "ldo1", ..., "ldo5", "buck1", ..., "buck5" and "ldolpsr" + for ldolpsr regulator, "ldodvref" for ldodvref reglator. + + rohm,vsel-gpios: +description: + GPIO used to control ldo4 state (when ldo4 is controlled by GPIO). + + rohm,dvs-run-voltage: +description: + PMIC "RUN" state voltage in uV when PMIC HW states are used. See + comments below for bucks/LDOs which support this. 0 means + regulator should be disabled at RUN state. +$ref: "/schemas/types.yaml#/definitions/uint32" +minimum: 0 +maximum: 330 + + rohm,dvs-snvs-voltage: +description: + Whether to keep regulator enabled at "SNVS" state or not. + 0 means regulator should be disabled at SNVS state, non zero voltage + keeps regulator enabled. BD71815 does not change voltage level + when PMIC transitions to SNVS.SNVS voltage depends on the previous + state (from which the PMIC transitioned to SNVS). +$ref: "/schemas/types.yaml#/definitions/uint32" +minimum: 0 +maximum: 330 + + rohm,dvs-suspend-voltage: +description: + PMIC "SUSPEND" state voltage in uV when PMIC HW states are used. See + comments below for bucks/LDOs which support this. 0 means + regulator should be disabled at SUSPEND state. +$ref: "/schemas/types.yaml#/definitions/uint32" +minimum: 0 +maximum: 330 + + rohm,dvs-lpsr-voltage: +description: + PMIC "LPSR" state voltage in uV when PMIC HW states are used. See + comments below for bucks/LDOs which support this. 0 means + regulator should be disabled at LPSR state. +$ref: "/schemas/types.yaml#/definitions/uint32" +minimum: 0 +maximum: 330 + +# Bucks 1 and 2 support giving separate voltages for operational states +# (RUN /CLEAN according to data-sheet) and non operational states +# (LPSR/SUSPEND). The voltage is automatically changed when HW +# state changes. Omitting these properties from bucks 1 and 2 leave +# buck voltages to not be toggled by HW state. Enable status may still +# be toggled by state changes depending on HW default settings. +# +# Bucks 3-5 and ldos 1-5 support setting the RUN state voltage here. +# Given RUN voltage is used at all states if regulator is enabled at +# given state. +# Values given for other states are regarded as enable/disable at +# given state (see below). +# +# All regulators except WLED support specifying enable/disable status +# for each of the HW states (RUN/SNVS/SUSPEND/LPSR). HW defaults can +# be overridden by setting voltage to 0 (regulator disabled at given +# state) or non-zero (regulator enabled at given state). Please note +# that setting non zero voltages for bucks
[PATCH v2 05/17] dt_bindings: bd71828: Add clock output mode
The BD71828 allows configuring the clk32kout pin mode to CMOS or open-drain. Add device-tree property for specifying the preferred mode. Signed-off-by: Matti Vaittinen --- Changes from v1: switched clk-mode property from string type to tristated one as suggested by Rob. .../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml index 3a6a1a26e2b3..8380166d176c 100644 --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml @@ -44,6 +44,12 @@ properties: clock-output-names: const: bd71828-32k-out + rohm,clkout-open-drain: +description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos". +$ref: "/schemas/types.yaml#/definitions/uint32" +minimum: 0 +maximum: 1 + rohm,charger-sense-resistor-ohms: minimum: 1000 maximum: 5000 -- 2.25.4 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
Re: [PATCH] PCI: functions/pci-epf-test: fix missing destroy_workqueue() on error in pci_epf_test_init
Hi Qinglang,
On 18/01/21 6:17 pm, Lorenzo Pieralisi wrote:
> On Wed, Oct 28, 2020 at 05:15:49PM +0800, Qinglang Miao wrote:
>> Add the missing destroy_workqueue() before return from
>> pci_epf_test_init() in the error handling case.
>>
>> Signed-off-by: Qinglang Miao
>> ---
>> drivers/pci/endpoint/functions/pci-epf-test.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> Need Kishon's ack.
>
> Lorenzo
Can you also add destroy_workqueue() in pci_epf_test_exit()?
Thank You,
Kishon
>
>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
>> b/drivers/pci/endpoint/functions/pci-epf-test.c
>> index e4e51d884..6854f2525 100644
>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
>> @@ -918,6 +918,7 @@ static int __init pci_epf_test_init(void)
>> ret = pci_epf_register_driver(_driver);
>> if (ret) {
>> pr_err("Failed to register pci epf test driver --> %d\n", ret);
>> +destroy_workqueue(kpcitest_workqueue);
>> return ret;
>> }
>>
>> --
>> 2.23.0
>>
[PATCH v2 01/17] regulator: bd718x7, bd71828, Fix dvs voltage levels
The ROHM BD718x7 and BD71828 drivers support setting HW state
specific voltages from device-tree. This is used also by various
in-tree DTS files.
These drivers do incorrectly try to compose bit-map using enum
values. By a chance this works for first two valid levels having
values 1 and 2 - but setting values for the rest of the levels
do indicate capbility of setting values for first levels as
well. Luckily the regulators which support settin values for
SUSPEND/LPSR do usually also support setting values for RUN
and IDLE too - thus this has not been such a fatal issue.
Fix this by defining the old enum values as bits and using
new enum in parsing code. This allows keeping existing IC
specific drivers intact and only adding the defines and
slightly changing the rohm-regulator.c
Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7
specific parts")
Signed-off-by: Matti Vaittinen
---
Please note that this same change has been sent individually:
https://lore.kernel.org/lkml/20210118075851.GA1016281@localhost.localdomain/
It is present in this series only because some patches depend on it.
drivers/regulator/rohm-regulator.c | 9 ++---
include/linux/mfd/rohm-generic.h | 14 ++
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/rohm-regulator.c
b/drivers/regulator/rohm-regulator.c
index 399002383b28..5c558b153d55 100644
--- a/drivers/regulator/rohm-regulator.c
+++ b/drivers/regulator/rohm-regulator.c
@@ -52,9 +52,12 @@ int rohm_regulator_set_dvs_levels(const struct
rohm_dvs_config *dvs,
char *prop;
unsigned int reg, mask, omask, oreg = desc->enable_reg;
- for (i = 0; i < ROHM_DVS_LEVEL_MAX && !ret; i++) {
- if (dvs->level_map & (1 << i)) {
- switch (i + 1) {
+ for (i = 0; i < ROHM_DVS_LEVEL_VALID_AMOUNT && !ret; i++) {
+ int bit;
+
+ bit = BIT(i);
+ if (dvs->level_map & bit) {
+ switch (bit) {
case ROHM_DVS_LEVEL_RUN:
prop = "rohm,dvs-run-voltage";
reg = dvs->run_reg;
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index 4283b5b33e04..2b85b9deb03a 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -20,14 +20,12 @@ struct rohm_regmap_dev {
struct regmap *regmap;
};
-enum {
- ROHM_DVS_LEVEL_UNKNOWN,
- ROHM_DVS_LEVEL_RUN,
- ROHM_DVS_LEVEL_IDLE,
- ROHM_DVS_LEVEL_SUSPEND,
- ROHM_DVS_LEVEL_LPSR,
- ROHM_DVS_LEVEL_MAX = ROHM_DVS_LEVEL_LPSR,
-};
+#define ROHM_DVS_LEVEL_RUN BIT(0)
+#define ROHM_DVS_LEVEL_IDLEBIT(1)
+#define ROHM_DVS_LEVEL_SUSPEND BIT(2)
+#define ROHM_DVS_LEVEL_LPSRBIT(3)
+#define ROHM_DVS_LEVEL_VALID_AMOUNT4
+#define ROHM_DVS_LEVEL_UNKNOWN 0
/**
* struct rohm_dvs_config - dynamic voltage scaling register descriptions
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
[PATCH v2 00/17] Support ROHM BD71815 PMIC
Patch series introducing support for ROHM BD71815 PMIC Please note that this series depends on previously sent patches. Already merged regulator patches (in regulator tree - not yet in Linus' tree): [PATCH] regulator: ROHM bd7: Do not depend on parent driver data https://lore.kernel.org/lkml/20210105130221.GA3438042@localhost.localdomain/ [PATCH] regulator: bd718x7: Stop using parent data https://lore.kernel.org/lkml/20210107122355.GA35080@localhost.localdomain/ Already merged GPIO patch (in GPIO tree - not yet in Linus' tree): [PATCH] gpio: bd7: Do not depend on parent driver data https://lore.kernel.org/lkml/20210105125335.GA3430233@localhost.localdomain/ This series also includes already sent patches: The patches 1, 2 and 3 have been sent separately to mfd/regulator, rtc and clk subsystems - but they have not yet been reviewed / applied. They are present also in this series because the series depends on those changes. I will drop those patches from this series if they get merged to (MFD or regulator)/RTC/clk trees from previous submits. patch 1 previous submit: regulator: bd718x7, bd71828, Fix dvs voltage levels https://lore.kernel.org/lkml/20210118075851.GA1016281@localhost.localdomain/ patch 2 previous submit: rtc: bd70528: Do not require parent data https://lore.kernel.org/lkml/20210105152350.GA3714833@localhost.localdomain/ patch 3 previous submit: clk: BD718x7: Do not depend on parent driver data https://lore.kernel.org/lkml/20210105123028.GA3409663@localhost.localdomain/ Please note that due to the dependencies all of the patches are probably not applying cleanly to all subsystem trees. (regulator/RTC patches to other subsystems). I understand it perfectly well if this series can't be merged before all dependencies are merged to all relevant subsystem trees but I would be grateful if I got the first set of review comments even before that. ROHM BD71815 is a power management IC used in some battery powered systems. It contains regulators, GPO(s), charger + coulomb counter, RTC and a clock gate. All regulators can be controlled via I2C. LDO4 can additionally be set to be enabled/disabled by a GPIO. LDO3 voltage could be selected from two voltages written into separate VSEL reisters using GPIO but this mode is not supported by driver. On top of that the PMIC has the typical HW state machine which is present also on many other ROHM PMICs. IC contains two GPOs - but one of the GPOs is marked as GND in data-sheet. Thus the driver by default only exposes one GPO. The second GPO can be enabled by special DT property. RTC is almost similar to what is on BD71828. For currently used features only the register address offset to RTC block differs. The charger driver is not included in this series. ROHM has a charger driver with some fuel-gauging logig written in but this is not included here. I am working on separating the logic from HW specific driver and supporting both BD71815 and BD71828 chargers in separate patch series. Changelog v2: - Rebased on top of v5.11-rc3 - Added another "preliminary patch" which fixes HW-dvs voltage handling (patch 1) - split regulator patch to two. - changed dt-binding patch ordering. regulators: - staticized probe - removed some unnecessary defines - updated comments - split rohm-regulator patch adding SNVS and supporting simple linear mapping into two - one adding support for mapping, other adding SNVS. GPIO: - removed unnecessary headers - clarified dev/parent->dev usage - removed forgotten #define DEBUG dt-bindings: - changed patch order to meet ref-dependencies - added missing regulator nodes - changed string property for clk mode to tristated MFD: - header cleanups. CLK: - fixed commit message Matti Vaittinen (17): regulator: bd718x7, bd71828, Fix dvs voltage levels rtc: bd70528: Do not require parent data clk: BD718x7: Do not depend on parent driver data mfd: bd718x7: simplify by cleaning unnecessary device data dt_bindings: bd71828: Add clock output mode dt_bindings: regulator: Add ROHM BD71815 PMIC regulators dt_bindings: mfd: Add ROHM BD71815 PMIC mfd: Add ROHM BD71815 ID mfd: Support for ROHM BD71815 PMIC core gpio: support ROHM BD71815 GPOs regulator: helpers: Export helper voltage listing regulator: rohm-regulator: linear voltage support regulator: rohm-regulator: Support SNVS HW state. regulator: Support ROHM BD71815 regulators clk: bd718x7: Add support for clk gate on ROHM BD71815 PMIC rtc: bd70528: Support RTC on ROHM BD71815 MAINTAINERS: Add ROHM BD71815AGW .../bindings/mfd/rohm,bd71815-pmic.yaml | 202 ++ .../bindings/mfd/rohm,bd71828-pmic.yaml | 6 + .../regulator/rohm,bd71815-regulator.yaml | 116 +++ MAINTAINERS | 3 + drivers/clk/clk-bd718x7.c | 21 +- drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile
Re: linux-next: boot failure after merge of the iomem-mmap-vs-gup tree
Hi all,
On Wed, 13 Jan 2021 16:29:48 +1100 Stephen Rothwell
wrote:
>
> After merging the iomem-mmap-vs-gup tree, today's linux-next boot test
> (powerpc pseries_le_defconfig) failed like this:
>
> EEH: pSeries platform initialized
> PCI: Probing PCI hardware
> BUG: Kernel NULL pointer dereference on write at 0x0030
> Faulting instruction address: 0xc013bf4c
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc3 #2
> NIP: c013bf4c LR: c07a9ee8 CTR:
> REGS: c63a3610 TRAP: 0380 Not tainted (5.11.0-rc3)
> MSR: 82009033 CR: 84002440 XER:
>
> CFAR: c07a9ee4 IRQMASK: 0
> GPR00: c07a9ee8 c63a38b0 c13d8100
> c6061300
> GPR04: 0b20 c0f11738
>
> GPR08: c07a7ab0 c07a7a40
> 2d6770696f73
> GPR12: c15b c0013120
>
> GPR16:
>
> GPR20:
>
> GPR24: c6210de8 c6167120 c6620b20
>
> GPR28: c6167120 0180 c6061300
> c6167000
> NIP [c013bf4c] iomem_get_mapping+0x1c/0x30
> LR [c07a9ee8] pci_create_legacy_files+0xa8/0x1c0
> Call Trace:
> [c63a38b0] [c07a9e84] pci_create_legacy_files+0x44/0x1c0
> (unreliable)
> [c63a3930] [c0795198] pci_register_host_bridge+0x288/0x510
> [c63a3a60] [c0795514] pci_create_root_bus+0xf4/0x150
> [c63a3ac0] [c006d424] pcibios_scan_phb+0xe4/0x270
> [c63a3b70] [c1010b40] pcibios_init+0x8c/0x128
> [c63a3bf0] [c0012b70] do_one_initcall+0x60/0x2c0
> [c63a3cc0] [c10046b4] kernel_init_freeable+0x2e8/0x380
> [c63a3da0] [c0013144] kernel_init+0x2c/0x168
> [c63a3e10] [c000dff0] ret_from_kernel_thread+0x5c/0x6c
> Instruction dump:
> 7c634850 4e800020 6000 6000 6042 3c4c012a 3842c1d0 7c0802a6
> 6000 3d22000d e929caf8 7c2004ac 4e800020 6000 6000
> ---[ end trace 77f55ece72f02708 ]---
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
>
> Caused by commit
>
> 85482fbab59e ("PCI: Revoke mappings like devmem")
>
> Reverting that commit fixes the boot, so I have done that for today.
I am still reverting this commit.
--
Cheers,
Stephen Rothwell
pgpQW3shjVh8k.pgp
Description: OpenPGP digital signature
[PATCH v2 0/3] Added ZynqMP pinctrl driver
Added support for Xilinx ZynqMP pinctrl driver support and also updated the Xilinx firmware driver to support pinctrl functionality. This driver will query the pin information from the firmware and allow configuring the pins as per the request. changes in v2: - Use pattern for pin names in yaml file. - Updated to support multiple groups and pins. - Added type ref for the vendor specific properties. - Removed 'schmitt-cmos', instead used common properties. - Removed macros for drive-strength property. This might be resend for some people, as i had some trouble with my email server earlier. Sai Krishna Potthuri (3): firmware: xilinx: Added pinctrl support dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver pinctrl: Added Xilinx ZynqMP pinctrl driver support .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 337 ++ drivers/firmware/xilinx/zynqmp.c | 114 ++ drivers/pinctrl/Kconfig | 13 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-zynqmp.c | 1031 + include/dt-bindings/pinctrl/pinctrl-zynqmp.h | 23 + include/linux/firmware/xlnx-zynqmp.h | 90 ++ 7 files changed, 1609 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h -- 2.17.1
[PATCH v2 1/3] firmware: xilinx: Added pinctrl support
Add pinctrl support to query platform specific information (pins)
from firmware.
Signed-off-by: Sai Krishna Potthuri
---
drivers/firmware/xilinx/zynqmp.c | 114 +++
include/linux/firmware/xlnx-zynqmp.h | 90 +
2 files changed, 204 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index efb8a66efc68..299c3d5a9ebd 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -784,6 +784,120 @@ int zynqmp_pm_fpga_get_status(u32 *value)
}
EXPORT_SYMBOL_GPL(zynqmp_pm_fpga_get_status);
+/**
+ * zynqmp_pm_pinctrl_request - Request Pin from firmware
+ * @pin: Pin number to request
+ *
+ * This function requests pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_request(const u32 pin)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_REQUEST, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_request);
+
+/**
+ * zynqmp_pm_pinctrl_release - Inform firmware that Pin control is released
+ * @pin: Pin number to release
+ *
+ * This function release pin from firmware.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_release(const u32 pin)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_RELEASE, pin, 0, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_release);
+
+/**
+ * zynqmp_pm_pinctrl_get_function - Read function id set for the given pin
+ * @pin: Pin number
+ * @id: Buffer to store function ID
+ *
+ * This function provides the function currently set for the given pin.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_pinctrl_get_function(const u32 pin, u32 *id)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!id)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_PINCTRL_GET_FUNCTION, pin, 0,
+ 0, 0, ret_payload);
+ *id = ret_payload[1];
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_function);
+
+/**
+ * zynqmp_pm_pinctrl_set_function - Set requested function for the pin
+ * @pin: Pin number
+ * @id: Function ID to set
+ *
+ * This function sets requested function for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_function(const u32 pin, const u32 id)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_SET_FUNCTION, pin, id,
+ 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_function);
+
+/**
+ * zynqmp_pm_pinctrl_get_config - Get configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to get
+ * @value: Buffer to store parameter value
+ *
+ * This function gets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_get_config(const u32 pin, const u32 param,
+u32 *value)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!value)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_GET, pin, param,
+ 0, 0, ret_payload);
+ *value = ret_payload[1];
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_get_config);
+
+/**
+ * zynqmp_pm_pinctrl_set_config - Set configuration parameter for the pin
+ * @pin: Pin number
+ * @param: Parameter to set
+ * @value: Parameter value to set
+ *
+ * This function sets requested configuration parameter for the given pin.
+ *
+ * Return: Returns status, either success or error+reason.
+ */
+int zynqmp_pm_pinctrl_set_config(const u32 pin, const u32 param,
+u32 value)
+{
+ return zynqmp_pm_invoke_fn(PM_PINCTRL_CONFIG_PARAM_SET, pin,
+ param, value, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_pinctrl_set_config);
+
/**
* zynqmp_pm_init_finalize() - PM call to inform firmware that the caller
*master has initialized its own power management
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..75aa6a5afa28 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -74,6 +74,12 @@ enum pm_api_id {
PM_FPGA_LOAD,
PM_FPGA_GET_STATUS,
PM_GET_CHIPID = 24,
+ PM_PINCTRL_REQUEST = 28,
+ PM_PINCTRL_RELEASE = 29,
+ PM_PINCTRL_GET_FUNCTION = 30,
+ PM_PINCTRL_SET_FUNCTION = 31,
+ PM_PINCTRL_CONFIG_PARAM_GET = 32,
+ PM_PINCTRL_CONFIG_PARAM_SET = 33,
PM_IOCTL = 34,
PM_QUERY_DATA,
PM_CLOCK_ENABLE,
@@ -125,6 +131,12 @@ enum pm_query_id {
PM_QID_CLOCK_GET_FIXEDFACTOR_PARAMS,
PM_QID_CLOCK_GET_PARENTS,
PM_QID_CLOCK_GET_ATTRIBUTES,
+ PM_QID_PINCTRL_GET_NUM_PINS = 6,
+
Re: [PATCH v1 1/7] coresight: etm-perf: Add support for PID tracing for kernel at EL2
Hi Mathieu
On 1/15/21 10:30 PM, Mathieu Poirier wrote:
Hey guys,
On Sat, Jan 09, 2021 at 03:44:29PM +0800, Leo Yan wrote:
From: Suzuki K Poulose
When the kernel is running at EL2, the PID is stored in CONTEXTIDR_EL2.
So, tracing CONTEXTIDR_EL1 doesn't give us the pid of the process.
Thus we should trace the VMID with VMIDOPT set to trace
CONTEXTIDR_EL2 instead of CONTEXTIDR_EL1. Given that we have an existing
config option "contextid" and this will be useful for tracing
virtual machines (when we get to support virtualization). So instead,
this patch adds a new option, contextid_in_vmid as a separate config.
Thus on an EL2 kernel, we will have two options available for
the perf tool. However, to make it easier for the user to
do pid tracing, we add a new format which will default to
"contextid" (on EL1 kernel) or "contextid_in_vmid" (on EL2
kernel). So that the user doesn't have to bother which EL the
kernel is running.
i.e, perf record -e cs_etm/pid/u --
will always do the "pid" tracing, independent of the kernel EL.
Also, the perf tool will be updated to automatically select
"pid" config instead of the "contextid" for system wide/CPU wide
mode.
Cc: Mathieu Poirier
Cc: Al Grant
Cc: Mike Leach
Signed-off-by: Suzuki K Poulose
Signed-off-by: Leo Yan
---
drivers/hwtracing/coresight/coresight-etm-perf.c | 14 ++
drivers/hwtracing/coresight/coresight-etm4x-core.c | 9 +
include/linux/coresight-pmu.h | 11 +++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index bdc34ca449f7..f763def145e4 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -30,14 +30,28 @@ static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
/* ETMv3.5/PTM's ETMCR is 'config' */
PMU_FORMAT_ATTR(cycacc, "config:" __stringify(ETM_OPT_CYCACC));
PMU_FORMAT_ATTR(contextid,"config:" __stringify(ETM_OPT_CTXTID));
+PMU_FORMAT_ATTR(contextid_in_vmid, "config:"
__stringify(ETM_OPT_CTXTID_IN_VMID));
I am not convinced adding this new contextid_in_vmid is the best way forward.
PMU_FORMAT_ATTR(timestamp,"config:" __stringify(ETM_OPT_TS));
PMU_FORMAT_ATTR(retstack, "config:" __stringify(ETM_OPT_RETSTK));
/* Sink ID - same for all ETMs */
PMU_FORMAT_ATTR(sinkid, "config2:0-31");
+static ssize_t format_attr_pid_show(struct device *dev,
+ struct device_attribute *attr,
+ char *page)
+{
+ int pid_fmt = is_kernel_in_hyp_mode() ? ETM_OPT_CTXTID_IN_VMID :
ETM_OPT_CTXTID;
+
+ return sprintf(page, "config:%d\n", pid_fmt);
+}
+
+struct device_attribute format_attr_pid = __ATTR(pid, 0444,
format_attr_pid_show, NULL);
The same applies here. PMU format bits are options the PMU supports rather than
a representation of the hardware, making bit numbering arbitrary. A such we
don't explicitly need a contextid_in_vmid option. Making the current contextid
variable, the same it was done for 'pid', should be sufficient. Based on the
value carried by contexid, i.e 14 or 15, the perf tools will know where to get
the contextID.
With regards to backward functionality, user who hard code 'config' on the perf
command line won't get the results they want when the kernel is at EL2 anyway.
The kernel, with function is_kernel_in_hyp_mode(), is not an issue.
I did think about that. The reason behind using a new alias is vaguely mentioned
in the description. If a host perf session wants to trace a VM with the
contextid_el1,
there is no option for that with "contextid" flipped to trace "contextid_el2".
This is precisely why I preferred keeping both the hardware configurations
and let the kernel choose the right one for the EL, by having an alias.
i.e,
perf record -e cs_etm/contextid,contextid_in_vmid/ vm
could still trace the VM vcpu threads and the CID changes within
the VM. (This is triggered from the host, so VM support is not necessary).
If we decide not to do this, or change the meaning of contextid now
to mean "pid" and change it in the future back to what it really
means for supporting such scenarios above, then we are going to
be back where we are with the proposal.
Suzuki
Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver
On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
>
> On the success of virtio_gpu_object_create, add size of newly allocated
> bo to the tracled total_mem. In drm_gem_object_funcs.free, after the gem
> bo lost its last refcount, subtract the bo size from the tracked
> total_mem if the original underlying memory allocation is successful.
>
> Signed-off-by: Yiwei Zhang
Isn't this something that ideally we'd for everyone? Also tracepoint
for showing the total feels like tracepoint abuse, usually we show
totals somewhere in debugfs or similar, and tracepoint just for what's
happening (i.e. which object got deleted/created).
What is this for exactly?
-Daniel
> ---
> drivers/gpu/drm/virtio/Kconfig | 1 +
> drivers/gpu/drm/virtio/virtgpu_drv.h| 4
> drivers/gpu/drm/virtio/virtgpu_object.c | 19 +++
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index b925b8b1da16..e103b7e883b1 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> select DRM_KMS_HELPER
> select DRM_GEM_SHMEM_HELPER
> select VIRTIO_DMA_SHARED_BUFFER
> + select TRACE_GPU_MEM
> help
>This is the virtual GPU driver for virtio. It can be used with
>QEMU based VMMs (like KVM or Xen).
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6a232553c99b..7c60e7486bc4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -249,6 +249,10 @@ struct virtio_gpu_device {
> spinlock_t resource_export_lock;
> /* protects map state and host_visible_mm */
> spinlock_t host_visible_lock;
> +
> +#ifdef CONFIG_TRACE_GPU_MEM
> + atomic64_t total_mem;
> +#endif
> };
>
> struct virtio_gpu_fpriv {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index d69a5b6da553..1e16226cebbe 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -25,12 +25,29 @@
>
> #include
> #include
> +#ifdef CONFIG_TRACE_GPU_MEM
> +#include
> +#endif
>
> #include "virtgpu_drv.h"
>
> static int virtio_gpu_virglrenderer_workaround = 1;
> module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> 0400);
>
> +#ifdef CONFIG_TRACE_GPU_MEM
> +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> *vgdev,
> + s64 delta)
> +{
> + u64 total_mem = atomic64_add_return(delta, >total_mem);
> +
> + trace_gpu_mem_total(0, 0, total_mem);
> +}
> +#else
> +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *,
> s64)
> +{
> +}
> +#endif
> +
> int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
> *resid)
> {
> if (virtio_gpu_virglrenderer_workaround) {
> @@ -104,6 +121,7 @@ static void virtio_gpu_free_object(struct drm_gem_object
> *obj)
> struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
>
> if (bo->created) {
> + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> virtio_gpu_cmd_unref_resource(vgdev, bo);
> virtio_gpu_notify(vgdev);
> /* completion handler calls virtio_gpu_cleanup_object() */
> @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> virtio_gpu_object_attach(vgdev, bo, ents, nents);
> }
>
> + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> *bo_ptr = bo;
> return 0;
>
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
linux-next: Tree for Jan 19
Hi all, Changes since 20210118: The hid tree gained a conflict against the qcom tree. The drm tree still had its build failure so I used the version from next-20210107. The drm-intel tree still had its build failure from merging the drm tree, so I have used the version from next-20210108. I still reverted a commit from the iomem-mmap-vs-gup tree that caused a boot failure on PowerPC. The oprofile-removal tree lost its build failure. Non-merge commits (relative to Linus' tree): 3859 4166 files changed, 153036 insertions(+), 80251 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 333 trees (counting Linus' and 86 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (1e2a199f6ccd Merge tag 'spi-fix-v5.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi) Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2) Merging kbuild-current/fixes (0bc9bc1d8b2f Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3) Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten up inline asm constraints) Merging arm64-fixes/for-next/fixes (3ed86b9a7140 kasan, arm64: fix pointer tags in KASAN reports) Merging arm-soc-fixes/arm/fixes (8a996b2d8a03 ARM: dts: ux500: Reserve memory carveouts) Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1) Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry) Merging powerpc-fixes/fixes (41131a5e54ae powerpc/vdso: Fix clock_gettime_fallback for vdso32) Merging s390-fixes/fixes (a1a322a62dba s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (87fe04367d84 net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext) Merging bpf/master (e23a8d002198 Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in xfrm_policy_addr_delta()) Merging netfilter/master (c8a8ead01736 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (869f4fdaf4ca netfilter: nf_nat: Fix memleak in nf_nat_init) Merging wireless-drivers/master (952de419b617 mt76: mt7663s: fix rx buffer refcounting) Merging mac80211/master (c13cf5c15966 mac80211: check if atf has been disabled in __ieee80211_schedule_txq) Merging rdma-fixes/for-rc (19c329f68089 Linux 5.11-rc4) Merging sound-current/for-linus (c23010ffb20a Merge tag 'asoc-fix-v5.11-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (63e1267254ab Merge remote-tracking branch 'asoc/for-5.11' into asoc-linus) Merging regmap-fixes/for-linus (7c53f6b671f4 Linux 5.11-rc3) Merging regulator-fixes/for-linus (09db7311ca61 Merge v5.11-rc3) Merging spi-fixes/for-linus (4d163ad79b15 spi: cadence: cache reference clock rate during probe) Merging pci-current/for-linus (7c53f6b671f4 Linux 5.11-rc3) Merging driver-core.current/driver-core-linus (895bee270863 Revert "driver core: Reorder de
[PATCH v2 2/3] dt-bindings: pinctrl: Added binding for ZynqMP pinctrl driver
Added documentation and dt-bindings file which contains MIO pin configuration defines for Xilinx ZynqMP pinctrl driver. Signed-off-by: Sai Krishna Potthuri --- .../bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml | 337 ++ include/dt-bindings/pinctrl/pinctrl-zynqmp.h | 23 ++ 2 files changed, 360 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml create mode 100644 include/dt-bindings/pinctrl/pinctrl-zynqmp.h diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml new file mode 100644 index ..9f2efbafcaa4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -0,0 +1,337 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/xlnx,zynqmp-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP Pinctrl + +maintainers: + - Sai Krishna Potthuri + - Rajan Vaja + +description: | + Please refer to pinctrl-bindings.txt in this directory for details of the + common pinctrl bindings used by client devices, including the meaning of the + phrase "pin configuration node". + + ZynqMP's pin configuration nodes act as a container for an arbitrary number of + subnodes. Each of these subnodes represents some desired configuration for a + pin, a group, or a list of pins or groups. This configuration can include the + mux function to select on those pin(s)/group(s), and various pin configuration + parameters, such as pull-up, slew rate, etc. + + Each configuration node can consist of multiple nodes describing the pinmux and + pinconf options. Those nodes can be pinmux nodes or pinconf nodes. + + The name of each subnode is not important; all subnodes should be enumerated + and processed purely based on their content. + +properties: + compatible: +const: xlnx,zynqmp-pinctrl + +patternProperties: + '^(.*-)?(default|gpio)$': +type: object +patternProperties: + '^mux(.*)$': +type: object +description: + Pinctrl node's client devices use subnodes for pin muxes, + which in turn use below standard properties. +$ref: pinmux-node.yaml# + +properties: + groups: +description: + List of groups to select (either this or "pins" must be + specified), available groups for this subnode. +items: + oneOf: +- enum: [ethernet0_0_grp, ethernet1_0_grp, ethernet2_0_grp, + ethernet3_0_grp, gemtsu0_0_grp, gemtsu0_1_grp, + gemtsu0_2_grp, mdio0_0_grp, mdio1_0_grp, + mdio1_1_grp, mdio2_0_grp, mdio3_0_grp, + qspi0_0_grp, qspi_ss_0_grp, qspi_fbclk_0_grp, + spi0_0_grp, spi0_ss_0_grp, spi0_ss_1_grp, + spi0_ss_2_grp, spi0_1_grp, spi0_ss_3_grp, + spi0_ss_4_grp, spi0_ss_5_grp, spi0_2_grp, + spi0_ss_6_grp, spi0_ss_7_grp, spi0_ss_8_grp, + spi0_3_grp, spi0_ss_9_grp, spi0_ss_10_grp, + spi0_ss_11_grp, spi0_4_grp, spi0_ss_12_grp, + spi0_ss_13_grp, spi0_ss_14_grp, spi0_5_grp, + spi0_ss_15_grp, spi0_ss_16_grp, spi0_ss_17_grp, + spi1_0_grp, spi1_ss_0_grp, spi1_ss_1_grp, + spi1_ss_2_grp, spi1_1_grp, spi1_ss_3_grp, + spi1_ss_4_grp, spi1_ss_5_grp, spi1_2_grp, + spi1_ss_6_grp, spi1_ss_7_grp, spi1_ss_8_grp, + spi1_3_grp, spi1_ss_9_grp, spi1_ss_10_grp, + spi1_ss_11_grp, spi1_4_grp, spi1_ss_12_grp, + spi1_ss_13_grp, spi1_ss_14_grp, spi1_5_grp, + spi1_ss_15_grp, spi1_ss_16_grp, spi1_ss_17_grp, + sdio0_0_grp, sdio0_1_grp, sdio0_2_grp, + sdio0_3_grp, sdio0_4_grp, sdio0_5_grp, + sdio0_6_grp, sdio0_7_grp, sdio0_8_grp, + sdio0_9_grp, sdio0_10_grp, sdio0_11_grp, + sdio0_12_grp, sdio0_13_grp, sdio0_14_grp, + sdio0_15_grp, sdio0_16_grp, sdio0_17_grp, + sdio0_18_grp, sdio0_19_grp, sdio0_20_grp, + sdio0_21_grp, sdio0_22_grp, sdio0_23_grp, + sdio0_24_grp, sdio0_25_grp, sdio0_26_grp, + sdio0_27_grp, sdio0_28_grp, sdio0_29_grp, + sdio0_30_grp, sdio0_31_grp, sdio0_32_grp, + sdio0_pc_0_grp, sdio0_cd_0_grp, sdio0_wp_0_grp, + sdio0_pc_1_grp, sdio0_cd_1_grp, sdio0_wp_1_grp, + sdio0_pc_2_grp, sdio0_cd_2_grp,
Re: [PATCH bpf-next] xsk: build skb by page
On Mon, Jan 18, 2021 at 5:38 PM Alexander Lobakin wrote:
>
> > From: Magnus Karlsson
> > Date: Mon, 18 Jan 2021 16:10:40 +0100
> >
> > On Mon, Jan 18, 2021 at 3:47 PM Alexander Lobakin wrote:
> > >
> > > From: Alexander Lobakin
> > > Date: Mon, 18 Jan 2021 13:00:17 +
> > >
> > > > From: Yunsheng Lin
> > > > Date: Mon, 18 Jan 2021 20:40:52 +0800
> > > >
> > > >> On 2021/1/16 10:44, Xuan Zhuo wrote:
> > > >>> This patch is used to construct skb based on page to save memory copy
> > > >>> overhead.
> > > >>>
> > > >>> This has one problem:
> > > >>>
> > > >>> We construct the skb by fill the data page as a frag into the skb. In
> > > >>> this way, the linear space is empty, and the header information is
> > > >>> also
> > > >>> in the frag, not in the linear space, which is not allowed for some
> > > >>> network cards. For example, Mellanox Technologies MT27710 Family
> > > >>> [ConnectX-4 Lx] will get the following error message:
> > > >>>
> > > >>> mlx5_core :3b:00.1 eth1: Error cqe on cqn 0x817, ci 0x8, qn
> > > >>> 0x1dbb, opcode 0xd, syndrome 0x1, vendor syndrome 0x68
> > > >>> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > >>> 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > >>> 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > >>> 0030: 00 00 00 00 60 10 68 01 0a 00 1d bb 00 0f 9f d2
> > > >>> WQE DUMP: WQ size 1024 WQ cur size 0, WQE index 0xf, len: 64
> > > >>> : 00 00 0f 0a 00 1d bb 03 00 00 00 08 00 00 00 00
> > > >>> 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > >>> 0020: 00 00 00 2b 00 08 00 00 00 00 00 05 9e e3 08 00
> > > >>> 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > >>> mlx5_core :3b:00.1 eth1: ERR CQE on SQ: 0x1dbb
> > > >>>
> > > >>> I also tried to use build_skb to construct skb, but because of the
> > > >>> existence of skb_shinfo, it must be behind the linear space, so this
> > > >>> method is not working. We can't put skb_shinfo on desc->addr, it will
> > > >>> be
> > > >>> exposed to users, this is not safe.
> > > >>>
> > > >>> Finally, I added a feature NETIF_F_SKB_NO_LINEAR to identify whether
> > > >>> the
> > > >>
> > > >> Does it make sense to use ETHTOOL_TX_COPYBREAK tunable in ethtool to
> > > >> configure if the data is copied or not?
> > > >
> > > > As far as I can grep, only mlx4 supports this, and it has a different
> > > > meaning in that driver.
> > > > So I guess a new netdev_feature would be a better solution.
> > > >
> > > >>> network card supports the header information of the packet in the frag
> > > >>> and not in the linear space.
> > > >>>
> > > >>> Performance Testing
> > > >>>
> > > >>> The test environment is Aliyun ECS server.
> > > >>> Test cmd:
> > > >>> ```
> > > >>> xdpsock -i eth0 -t -S -s
> > > >>> ```
> > > >>>
> > > >>> Test result data:
> > > >>>
> > > >>> size64 512 10241500
> > > >>> copy1916747 1775988 1600203 1440054
> > > >>> page1974058 1953655 1945463 1904478
> > > >>> percent 3.0%10.0% 21.58% 32.3%
> > > >>>
> > > >>> Signed-off-by: Xuan Zhuo
> > > >>> Reviewed-by: Dust Li
> > > >>> ---
> > > >>> drivers/net/virtio_net.c| 2 +-
> > > >>> include/linux/netdev_features.h | 5 +-
> > > >>> net/ethtool/common.c| 1 +
> > > >>> net/xdp/xsk.c | 108
> > > >>> +---
> > > >>> 4 files changed, 97 insertions(+), 19 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > >>> index 4ecccb8..841a331 100644
> > > >>> --- a/drivers/net/virtio_net.c
> > > >>> +++ b/drivers/net/virtio_net.c
> > > >>> @@ -2985,7 +2985,7 @@ static int virtnet_probe(struct virtio_device
> > > >>> *vdev)
> > > >>> /* Set up network device as normal. */
> > > >>> dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE;
> > > >>> dev->netdev_ops = _netdev;
> > > >>> - dev->features = NETIF_F_HIGHDMA;
> > > >>> + dev->features = NETIF_F_HIGHDMA | NETIF_F_SKB_NO_LINEAR;
> > > >>>
> > > >>> dev->ethtool_ops = _ethtool_ops;
> > > >>> SET_NETDEV_DEV(dev, >dev);
> > > >>> diff --git a/include/linux/netdev_features.h
> > > >>> b/include/linux/netdev_features.h
> > > >>> index 934de56..8dd28e2 100644
> > > >>> --- a/include/linux/netdev_features.h
> > > >>> +++ b/include/linux/netdev_features.h
> > > >>> @@ -85,9 +85,11 @@ enum {
> > > >>>
> > > >>> NETIF_F_HW_MACSEC_BIT, /* Offload MACsec operations */
> > > >>>
> > > >>> + NETIF_F_SKB_NO_LINEAR_BIT, /* Allow skb linear is empty */
> > > >>> +
> > > >>> /*
> > > >>> * Add your fresh new feature above and remember to update
> > > >>> -* netdev_features_strings[] in net/core/ethtool.c and maybe
> > > >>> +* netdev_features_strings[] in net/ethtool/common.c and maybe
> > > >>> * some feature mask
Re: [PATCH v6 1/6] scsi: ufs: Add "wb_on" sysfs node to control WB on/off
On 18/01/21 10:10 pm, Bean Huo wrote: > From: Bean Huo > > Currently UFS WriteBooster driver uses clock scaling up/down to set > WB on/off, for the platform which doesn't support UFSHCD_CAP_CLK_SCALING, > WB will be always on. Provide a sysfs attribute to enable/disable WB > during runtime. Write 1/0 to "wb_on" sysfs node to enable/disable UFS WB. Is it so, that after a full reset, WB is always enabled again? Is that intended?
Re: [PATCH v5 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On 1/18/21 10:52 PM, Vijayanand Jitta wrote: > > > On 1/19/2021 4:23 AM, Randy Dunlap wrote: >> On 1/18/21 1:56 AM, vji...@codeaurora.org wrote: >>> From: Yogesh Lal >>> >>> Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE. >>> >>> Aim is to have configurable value for STACK_HASH_SIZE, >>> so depend on use case one can configure it. >>> >>> One example is of Page Owner, default value of >>> STACK_HASH_SIZE lead stack depot to consume 8MB of static memory. >>> Making it configurable and use lower value helps to enable features like >>> CONFIG_PAGE_OWNER without any significant overhead. >>> >>> Signed-off-by: Yogesh Lal >>> Signed-off-by: Vinayak Menon >>> Signed-off-by: Vijayanand Jitta >> >> Hi, >> >> Did you see >> https://lore.kernel.org/lkml/202101050729.cwtd47yw-...@intel.com/ >> >> It seems that arch/arc/ does not have: >>arc-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': >>(.text+0x6): undefined reference to `__irqentry_text_start' arc-elf-ld: (.text+0x6): undefined reference to `__irqentry_text_start' arc-elf-ld: (.text+0x26): undefined reference to `__irqentry_text_end' arc-elf-ld: (.text+0x26): undefined reference to `__irqentry_text_end' arc-elf-ld: (.text+0x34): undefined reference to `__softirqentry_text_start' arc-elf-ld: (.text+0x34): undefined reference to `__softirqentry_text_start' arc-elf-ld: (.text+0x3c): undefined reference to `__softirqentry_text_end' arc-elf-ld: (.text+0x3c): undefined reference to `__softirqentry_text_end' >> >> >> >> > > The above issue seems to be because of a different patch. > This one > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=505a0ef15f96c6c43ec719c9fc1833d98957bb39 > > I didn't really get why you referred that here. Yes, I noticed that later. Sorry about that. Maybe Alexander P. can look into it... thanks. -- ~Randy You can't do anything without having to do something else first. -- Belefant's Law
Re: [PATCH bpf] samples/bpf: Update README.rst and Makefile for manually compiling LLVM and clang
On 1/18/21 7:53 PM, Tiezhu Yang wrote: In the current samples/bpf/README.rst, the url of llvm and clang git may be out of date, they are unable to access: Let us just rephrase the above more clearly, something like below. The current clang/llvm build procedure in samples/bpf/README.rst is out of date. See below that the links are not accessible any more. $ git clone http://llvm.org/git/llvm.git Cloning into 'llvm'... fatal: unable to access 'http://llvm.org/git/llvm.git/ ': Maximum (20) redirects followed $ git clone --depth 1 http://llvm.org/git/clang.git Cloning into 'clang'... fatal: unable to access 'http://llvm.org/git/clang.git/ ': Maximum (20) redirects followed The llvm community has adopted new ways to build the compiler. [followed by your descriptions below] There are different ways to build llvm/clang, I find the Clang Getting Started page [1] has one way, as Yonghong said, it is better to just copy the build procedure in Documentation/bpf/bpf_devel_QA.rst to keep consistent. I verified the procedure and it is proved to be feasible, so we should update README.rst to reflect the reality. At the same time, update the related comment in Makefile. [1] https://clang.llvm.org/get_started.html Signed-off-by: Tiezhu Yang Ack with minor nits in the above. Also, this is a documentation update. I think it is okay to target the patch to bpf-next instead of bpf. Acked-by: Yonghong Song
Re: [PATCH v2 3/4] staging: hikey9xx: phy-hi3670-usb3.c: hi3670_is_abbclk_seleted() returns bool
On Thu, Jan 14, 2021 at 09:56:41AM -0800, Joe Perches wrote:
> On Thu, 2021-01-14 at 18:35 +0100, Mauro Carvalho Chehab wrote:
> > Instead of using 1/0 for true/false, change the type to boolean
> > and change the returned value.
> []
> > diff --git a/drivers/staging/hikey9xx/phy-hi3670-usb3.c
> > b/drivers/staging/hikey9xx/phy-hi3670-usb3.c
> []
> > @@ -326,24 +326,24 @@ static int hi3670_phy_set_params(struct hi3670_priv
> > *priv)
> > return ret;
> > }
> >
> > -static int hi3670_is_abbclk_seleted(struct hi3670_priv *priv)
> > +static bool hi3670_is_abbclk_seleted(struct hi3670_priv *priv)
>
> Presumably this should be "selected" not "seleted"
>
> > {
> > u32 reg;
> >
> > if (!priv->sctrl) {
> > dev_err(priv->dev, "priv->sctrl is null!\n");
> > - return 1;
> > + return true;
> > }
> >
> > if (regmap_read(priv->sctrl, SCTRL_SCDEEPSLEEPED, )) {
> > dev_err(priv->dev, "SCTRL_SCDEEPSLEEPED read failed!\n");
> > - return 1;
> > + return true;
> > }
> >
> > if ((reg & USB_CLK_SELECTED) == 0)
> > - return 1;
> > + return true;
> >
> > - return 0;
> > + return false;
> > }
>
> if (foo)
> return true;
> return false;
>
> should generally be consolidated into a single test.
I quite prefer the original format, but you're right about the return
looking reversed. Using "return !!(reg & USB_CLK_SELECTED);" is
especially problematic. I like !! but Linus has commented a couple
times that he doesn't like !!.
regards,
dan carpenter
Re: [RFC PATCH v3 1/5] usb: xhci-mtk: improve bandwidth scheduling with multi-TT
On Wed, 2021-01-13 at 17:43 +0800, Ikjoon Jang wrote:
> On Tue, Dec 22, 2020 at 5:35 PM Chunfeng Yun
> wrote:
> >
> > From: Zhanyong Wang
> >
> > After inserted the usb type-c 3.5mm dongle with headset, dmesg showed:
> > usb 1-1.1: new full-speed USB device number 5 using xhci-mtk
> > usb 1-1.1: New USB device found, idVendor=05ac, idProduct=110a,
> > bcdDevice=26.11
> > usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > usb 1-1.1: Product: USB-C to 3.5mm Headphone Jack Adapter
> > usb 1-1.1: Manufacturer: Apple, Inc.
> > usb 1-1.1: SerialNumber: DWH915501TFJKLTAM
> > xhci-mtk 1120.xhci: Not enough bandwidth!
> > usb 1-1.1: can't set config #2, error -28
> >
> > improve low-speed/full-speed INT/ISOC bandwidth scheduling with USB
> > muli-TT.
> >
> > Signed-off-by: Yaqii Wu
> > Signed-off-by: Chunfeng Yun
> > ---
> > v2~v3: no changes
> > ---
> > drivers/usb/host/xhci-mtk-sch.c | 91 -
> > drivers/usb/host/xhci-mtk.h | 8 ++-
> > 2 files changed, 84 insertions(+), 15 deletions(-)
> > mode change 100644 => 100755 drivers/usb/host/xhci-mtk-sch.c
> >
> > diff --git a/drivers/usb/host/xhci-mtk-sch.c
> > b/drivers/usb/host/xhci-mtk-sch.c
> > old mode 100644
> > new mode 100755
> > index 45c54d56ecbd..94292b9bbc63
> > --- a/drivers/usb/host/xhci-mtk-sch.c
> > +++ b/drivers/usb/host/xhci-mtk-sch.c
> > @@ -383,7 +383,9 @@ static int check_sch_tt(struct usb_device *udev,
> > u32 fs_budget_start;
> > u32 start_ss, last_ss;
> > u32 start_cs, last_cs;
> > - int i;
> > + u32 num_esit, base;
> > + int i, j;
> > + u32 tmp;
> >
> > start_ss = offset % 8;
> > fs_budget_start = (start_ss + 1) % 8;
> > @@ -398,10 +400,13 @@ static int check_sch_tt(struct usb_device *udev,
> > if (!(start_ss == 7 || last_ss < 6))
> > return -ERANGE;
> >
> > - for (i = 0; i < sch_ep->cs_count; i++)
> > - if (test_bit(offset + i, tt->split_bit_map))
> > + for (i = 0; i < sch_ep->cs_count; i++) {
> > + if (test_bit(offset + i, tt->ss_bit_map))
> > return -ERANGE;
> >
> > + if (test_bit(offset + i, tt->cs_bit_map))
> > + return -ERANGE;
> > + }
>
> Are there any reasons for doing this?
> Why can only one split packet be scheduled in a u-frame for isochronous out?
> This looks like overkill.
[From DR]: We will calculate the number of uframes based on the isoc out
ep maxp. Except for the last uframe, all other consumed bandwidth is
188. But to be safe, we also count the bandwidth consumed by the last SS
as 188.
>
> > } else {
> > u32 cs_count = DIV_ROUND_UP(sch_ep->maxpkt, FS_PAYLOAD_MAX);
> >
> > @@ -428,8 +433,10 @@ static int check_sch_tt(struct usb_device *udev,
> > if (cs_count > 7)
> > cs_count = 7; /* HW limit */
> >
> > - for (i = 0; i < cs_count + 2; i++) {
> > - if (test_bit(offset + i, tt->split_bit_map))
> > + if (test_bit(offset, tt->ss_bit_map))
> > + return -ERANGE;
> > + for (i = 0; i < cs_count; i++) {
> > + if (test_bit(offset + 2 + i, tt->cs_bit_map))
> > return -ERANGE;
> > }
> >
>
> same here. It would be much better to understand
> if you can provide some counterexamples of schedule
> that can happen when this bitmap checking logic is omitted.
[From DR] Maybe you are right, it will indeed double check. I will
delete the bandwidth check, and then perform a regression test.
>
> > @@ -445,11 +452,22 @@ static int check_sch_tt(struct usb_device *udev,
> > sch_ep->num_budget_microframes = sch_ep->esit;
> > }
> >
> > + num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
> > + for (i = 0; i < num_esit; i++) {
> > + base = sch_ep->offset + i * sch_ep->esit;
> > + for (j = 0; j < sch_ep->num_budget_microframes; j++) {
> > + tmp = tt->fs_bus_bw[base + j]
> > + + sch_ep->bw_cost_per_microframe;
> > + if (tmp > FS_PAYLOAD_MAX)
> > + return -ERANGE;
> > + }
> > + }
>
> I guess this is enough to check the bandwidth limit of the
> lower speed bus without a bitmap.
[From DR]As explained in issue tracker that ss cannot be overlapped.
This is a hub compatibility issue. Therefore we need bitmap to prevent
ss overlap.
Thanks
>
> > +
> > return 0;
> > }
> >
> > static void update_sch_tt(struct usb_device *udev,
> > - struct mu3h_sch_ep_info *sch_ep)
> > + struct mu3h_sch_ep_info *sch_ep, bool used)
> > {
> > struct mu3h_sch_tt *tt = sch_ep->sch_tt;
> > u32 base,
Re: [PATCH 2/2] ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence
Dear Jakub, dear Greg, Am 05.01.21 um 18:25 schrieb Greg KH: On Tue, Jan 05, 2021 at 06:16:59PM +0100, Paul Menzel wrote: Am 03.11.20 um 19:39 schrieb Jakub Kicinski: On Tue, 3 Nov 2020 08:35:09 +0100 Paul Menzel wrote: According to *Developer's Certificate of Origin 1.1* [3], it’s my understanding, that it is *not* required. The items (a), (b), and (c) are connected by an *or*. (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or Ack, but then you need to put yourself as the author, because it's you certifying that the code falls under (b). At least that's my understanding. Greg, can you please clarify, if it’s fine, if I upstream a patch authored by somebody else and distributed under the GPLv2? I put them as the author and signed it off. You can't add someone else's signed-off-by, but you can add your own and keep them as the author, has happened lots of time in the past. Or, you can make the From: line be from you if the original author doesn't want their name/email in the changelog, we've done that as well, both are fine. Greg, thank you for the clarification. Jakub, with that out of the way, can you please take patch 2/2? Kind regards, Paul
[PATCH v2 3/3] pinctrl: Added Xilinx ZynqMP pinctrl driver support
Added pinctrl driver for Xilinx ZynqMP platform.
This driver queries pin information from firmware and registers
pin control accordingly.
Signed-off-by: Sai Krishna Potthuri
---
drivers/pinctrl/Kconfig | 13 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-zynqmp.c | 1031 ++
3 files changed, 1045 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 815095326e2d..25d3c7208975 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
help
This selects the pinctrl driver for Xilinx Zynq.
+config PINCTRL_ZYNQMP
+ bool "Pinctrl driver for Xilinx ZynqMP"
+ depends on ARCH_ZYNQMP
+ select PINMUX
+ select GENERIC_PINCONF
+ help
+ This selects the pinctrl driver for Xilinx ZynqMP platform.
+ This driver will query the pin information from the firmware
+ and allow configuring the pins.
+ Configuration can include the mux function to select on those
+ pin(s)/group(s), and various pin configuration parameters
+ such as pull-up, slew rate, etc.
+
config PINCTRL_INGENIC
bool "Pinctrl driver for the Ingenic JZ47xx SoCs"
default MACH_INGENIC
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f53933b2ff02..7e058739f0d5 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_PINCTRL_TB10X) += pinctrl-tb10x.o
obj-$(CONFIG_PINCTRL_ST) += pinctrl-st.o
obj-$(CONFIG_PINCTRL_STMFX)+= pinctrl-stmfx.o
obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_PINCTRL_ZYNQMP)+= pinctrl-zynqmp.o
obj-$(CONFIG_PINCTRL_INGENIC) += pinctrl-ingenic.o
obj-$(CONFIG_PINCTRL_RK805)+= pinctrl-rk805.o
obj-$(CONFIG_PINCTRL_OCELOT) += pinctrl-ocelot.o
diff --git a/drivers/pinctrl/pinctrl-zynqmp.c b/drivers/pinctrl/pinctrl-zynqmp.c
new file mode 100644
index ..ec0a5d0e22d5
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynqmp.c
@@ -0,0 +1,1031 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP pin controller
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Sai Krishna Potthuri
+ * Rajan Vaja
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "pinctrl-utils.h"
+
+#define ZYNQMP_PIN_PREFIX "MIO"
+#define PINCTRL_GET_FUNC_NAME_RESP_LEN 16
+#define MAX_FUNC_NAME_LEN 16
+#define MAX_GROUP_PIN 50
+#define END_OF_FUNCTIONS "END_OF_FUNCTIONS"
+#define NUM_GROUPS_PER_RESP6
+
+#define PINCTRL_GET_FUNC_GROUPS_RESP_LEN 12
+#define PINCTRL_GET_PIN_GROUPS_RESP_LEN12
+#define NA_GROUP -1
+#define RESERVED_GROUP -2
+
+#define DRIVE_STRENGTH_2MA 2
+#define DRIVE_STRENGTH_4MA 4
+#define DRIVE_STRENGTH_8MA 8
+#define DRIVE_STRENGTH_12MA12
+
+/**
+ * struct zynqmp_pmux_function - a pinmux function
+ * @name: Name of the pinmux function
+ * @groups:List of pingroups for this function
+ * @ngroups: Number of entries in @groups
+ * @node:` Firmware node matching with for function
+ *
+ * This structure holds information about pin control function
+ * and function group names supporting that function.
+ */
+struct zynqmp_pmux_function {
+ char name[MAX_FUNC_NAME_LEN];
+ const char * const *groups;
+ unsigned int ngroups;
+};
+
+/**
+ * struct zynqmp_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @groups:Pingroups
+ * @ngroups: Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ *
+ * This struct is stored as driver data and used to retrieve
+ * information regarding pin control functions, groups and
+ * group pins.
+ */
+struct zynqmp_pinctrl {
+ struct pinctrl_dev *pctrl;
+ const struct zynqmp_pctrl_group *groups;
+ unsigned int ngroups;
+ const struct zynqmp_pmux_function *funcs;
+ unsigned int nfuncs;
+};
+
+/**
+ * struct zynqmp_pctrl_group - Pin control group info
+ * @name: Group name
+ * @pins: Group pin numbers
+ * @npins: Number of pins in group
+ */
+struct zynqmp_pctrl_group {
+ const char *name;
+ unsigned int pins[MAX_GROUP_PIN];
+ unsigned int npins;
+};
+
+/**
+ * enum zynqmp_pin_config_param - possible pin configuration parameters
+ * @PIN_CONFIG_IOSTANDARD: if the pin can select an IO standard,
+ * the argument to this parameter (on a
+ * custom format) tells the driver which
+ * alternative IO standard to use
+ */
+enum zynqmp_pin_config_param {
+ PIN_CONFIG_IOSTANDARD = PIN_CONFIG_END + 1,
+};
+
+static const struct
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 16th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
[PATCH] usb: cdns3: Add support for TI's AM64 SoC
Add support for USB controller present on the AM64x SoC.
Signed-off-by: Aswath Govindraju
---
drivers/usb/cdns3/cdns3-ti.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 90e246601537..eccb1c766bba 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -214,6 +214,7 @@ static int cdns_ti_remove(struct platform_device *pdev)
static const struct of_device_id cdns_ti_of_match[] = {
{ .compatible = "ti,j721e-usb", },
+ { .compatible = "ti,am64-usb", },
{},
};
MODULE_DEVICE_TABLE(of, cdns_ti_of_match);
--
2.17.1
Re: [PATCH 08/22] perf daemon: Add config file change check
On Sun, Jan 3, 2021 at 7:05 AM Jiri Olsa wrote: > > Adding support to detect daemon's config file changes > and re-read the configuration when that happens. Hmm.. maybe some of the code in the previous commit can be moved here. Thanks, Namhyung > > Using inotify file descriptor pluged into the main > fdarray object for polling. > > Example: > > # cat ~/.perfconfig > [daemon] > base=/opt/perfdata > > [session-cycles] > run = -m 10M -e cycles --overwrite --switch-output -a > > Starting the daemon: > > # perf daemon start > > Check sessions: > > # perf daemon > [772262:daemon] base: /opt/perfdata > [772263:cycles] perf record -m 10M -e cycles --overwrite --switch-output -a > > Change '-m 10M' to '-m 20M', and check daemon log: > > # tail -f /opt/perfdata/output > [2021-01-02 20:31:41.234045] daemon started (pid 772262) > [2021-01-02 20:31:41.235072] reconfig: ruining session [cycles:772263]: -m > 10M -e cycles --overwrite --switch-output -a > [2021-01-02 20:32:08.310137] reconfig: session 'cycles' killed > [2021-01-02 20:32:08.310847] reconfig: ruining session [cycles:772338]: -m > 20M -e cycles --overwrite --switch-output -a > > And the session list: > > # perf daemon > [772262:daemon] base: /opt/perfdata > [772338:cycles] perf record -m 20M -e cycles --overwrite --switch-output -a > > Note the changed '-m 20M' option is in place. > > Signed-off-by: Jiri Olsa > ---
Re: [PATCH v5 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On 1/19/2021 4:23 AM, Randy Dunlap wrote: > On 1/18/21 1:56 AM, vji...@codeaurora.org wrote: >> From: Yogesh Lal >> >> Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE. >> >> Aim is to have configurable value for STACK_HASH_SIZE, >> so depend on use case one can configure it. >> >> One example is of Page Owner, default value of >> STACK_HASH_SIZE lead stack depot to consume 8MB of static memory. >> Making it configurable and use lower value helps to enable features like >> CONFIG_PAGE_OWNER without any significant overhead. >> >> Signed-off-by: Yogesh Lal >> Signed-off-by: Vinayak Menon >> Signed-off-by: Vijayanand Jitta > > Hi, > > Did you see > https://lore.kernel.org/lkml/202101050729.cwtd47yw-...@intel.com/ > > It seems that arch/arc/ does not have: >arc-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks': >(.text+0x6): undefined reference to `__irqentry_text_start' >>> arc-elf-ld: (.text+0x6): undefined reference to `__irqentry_text_start' >>> arc-elf-ld: (.text+0x26): undefined reference to `__irqentry_text_end' >>> arc-elf-ld: (.text+0x26): undefined reference to `__irqentry_text_end' >>> arc-elf-ld: (.text+0x34): undefined reference to `__softirqentry_text_start' >>> arc-elf-ld: (.text+0x34): undefined reference to `__softirqentry_text_start' >>> arc-elf-ld: (.text+0x3c): undefined reference to `__softirqentry_text_end' >>> arc-elf-ld: (.text+0x3c): undefined reference to `__softirqentry_text_end' > > > > The above issue seems to be because of a different patch. This one https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=505a0ef15f96c6c43ec719c9fc1833d98957bb39 I didn't really get why you referred that here. Thanks, Vijay -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC PATCH v3 1/8] Use refcount_t for ucounts reference counting
(Sorry for the gmail client) My 0.2, HTH: a) AFAIK, refcount_inc() (and similar friends) don't return any value b) they're designed to just WARN() if they saturate or if you're attempting to increment the value 0 (as it's possibly a UAF bug) c) refcount_inc_checked() is documented as "Similar to atomic_inc(), but will saturate at UINT_MAX and WARN" d) we should avoid using the __foo() when foo() 's present as far as is sanely possible... So is one expected to just fix things when they break? - as signalled by the WARN firing? -- Regards, kaiwan. On Tue, Jan 19, 2021 at 2:26 AM Alexey Gladkov wrote: > > On Mon, Jan 18, 2021 at 12:34:29PM -0800, Linus Torvalds wrote: > > On Mon, Jan 18, 2021 at 11:46 AM Alexey Gladkov > > wrote: > > > > > > Sorry about that. I thought that this code is not needed when switching > > > from int to refcount_t. I was wrong. > > > > Well, you _may_ be right. I personally didn't check how the return > > value is used. > > > > I only reacted to "it certainly _may_ be used, and there is absolutely > > no comment anywhere about why it wouldn't matter". > > I have not found examples where checked the overflow after calling > refcount_inc/refcount_add. > > For example in kernel/fork.c:2298 : > >current->signal->nr_threads++; >atomic_inc(>signal->live); >refcount_inc(>signal->sigcnt); > > $ semind search signal_struct.sigcnt > def include/linux/sched/signal.h:83 refcount_t > sigcnt; > m-- kernel/fork.c:723 put_signal_struct if > (refcount_dec_and_test(>sigcnt)) > m-- kernel/fork.c:1571 copy_signal refcount_set(>sigcnt, 1); > m-- kernel/fork.c:2298 copy_process > refcount_inc(>signal->sigcnt); > > It seems to me that the only way is to use __refcount_inc and then compare > the old value with REFCOUNT_MAX > > Since I have not seen examples of such checks, I thought that this is > acceptable. Sorry once again. I have not tried to hide these changes. > > -- > Rgrds, legion > >
[PATCH v1 1/1] arm64: dts: stingray: fix usb dma address translation
From: Bharat Gooty
Add a non-empty dma-ranges so that dma address translation
happens.
Fixes: 2013a4b684b6 ("arm64: dts: broadcom: clear the warnings caused by empty
dma-ranges")
Signed-off-by: Bharat Gooty
Signed-off-by: Rayagonda Kokatanur
---
arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
index aef8f2b00778..5401a646c840 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -4,11 +4,16 @@
*/
usb {
compatible = "simple-bus";
- dma-ranges;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0x6850 0x0 0x0040>;
+ /*
+* Internally, USB bus to the interconnect can only address up
+* to 40-bit
+*/
+ dma-ranges = <0 0 0 0 0x100 0x0>;
+
usbphy0: usb-phy@0 {
compatible = "brcm,sr-usb-combo-phy";
reg = <0x0 0x 0x0 0x100>;
--
2.17.1
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH 11/22] perf daemon: Add stop command
On Sun, Jan 3, 2021 at 7:05 AM Jiri Olsa wrote:
>
> Add 'perf daemon stop' command to stop daemon process
> and all running sessions.
>
> Example:
>
> # cat ~/.perfconfig
> [daemon]
> base=/opt/perfdata
>
> [session-cycles]
> run = -m 10M -e cycles --overwrite --switch-output -a
>
> [session-sched]
> run = -m 20M -e sched:* --overwrite --switch-output -a
>
> Starting the daemon:
>
> # perf daemon start
>
> Stopping the daemon
>
> # perf daemon stop
>
> Daemon is not running, nothing to connect to:
>
> # perf daemon
> connect error: Connection refused
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/builtin-daemon.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
> index a7ffbecf8d14..45748bb471ec 100644
> --- a/tools/perf/builtin-daemon.c
> +++ b/tools/perf/builtin-daemon.c
> @@ -524,6 +524,7 @@ static int setup_server_socket(struct daemon *daemon)
> enum {
> CMD_LIST = 0,
> CMD_SIGNAL = 1,
> + CMD_STOP = 2,
> CMD_MAX,
> };
>
> @@ -650,6 +651,10 @@ static int handle_server_socket(struct daemon *daemon,
> int sock_fd)
> case CMD_SIGNAL:
> ret = cmd_session_kill(daemon, , out);
> break;
> + case CMD_STOP:
> + done = 1;
> + pr_debug("perf daemon is exciting\n");
I can see how much you are excited. ;-)
Thanks,
Namhyung
> + break;
> default:
> break;
> }
> @@ -992,6 +997,27 @@ static int __cmd_signal(struct daemon *daemon, struct
> option parent_options[],
> return send_cmd(daemon, );
> }
>
> +static int __cmd_stop(struct daemon *daemon, struct option parent_options[],
> + int argc, const char **argv)
> +{
> + struct option start_options[] = {
> + OPT_PARENT(parent_options),
> + OPT_END()
> + };
> + union cmd cmd = { .cmd = CMD_STOP, };
> +
> + argc = parse_options(argc, argv, start_options, daemon_usage, 0);
> + if (argc)
> + usage_with_options(daemon_usage, start_options);
> +
> + if (setup_config(daemon)) {
> + pr_err("failed: config not found\n");
> + return -1;
> + }
> +
> + return send_cmd(daemon, );
> +}
> +
> int cmd_daemon(int argc, const char **argv)
> {
> struct option daemon_options[] = {
> @@ -1015,6 +1041,8 @@ int cmd_daemon(int argc, const char **argv)
> if (argc) {
> if (!strcmp(argv[0], "signal"))
> return __cmd_signal(&__daemon, daemon_options, argc,
> argv);
> + else if (!strcmp(argv[0], "stop"))
> + return __cmd_stop(&__daemon, daemon_options, argc,
> argv);
>
> pr_err("failed: unknown command '%s'\n", argv[0]);
> return -1;
> --
> 2.26.2
>
Re: linux-next: build warnings after merge of the jc_docs tree
Hi all, On Tue, 19 Jan 2021 17:13:03 +1100 Stephen Rothwell wrote: > > Hi all, > > After merging the jc_docs tree, today's linux-next build (KCONFIG_NAME) This was a "make htmldocs" -- Cheers, Stephen Rothwell pgpFv0_40bjTG.pgp Description: OpenPGP digital signature
kernel/sched/core.c:2709:20: warning: unused function 'rq_has_pinned_tasks'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1e2a199f6ccdc15cf111d68d212e2fd4ce65682e
commit: 3015ef4b98f53fe7eba4f5f82f562c0e074d213c sched/core: Make migrate
disable and CPU hotplug cooperative
date: 2 months ago
config: mips-randconfig-r033-20210119 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
22b68440e1647e16b5ee24b924986207173c02d1)
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 mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3015ef4b98f53fe7eba4f5f82f562c0e074d213c
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 3015ef4b98f53fe7eba4f5f82f562c0e074d213c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
kernel/sched/core.c:324:1: warning: unused function 'rq_csd_init'
rq_csd_init(struct rq call_single_data_t smp_call_func_t func)
^
kernel/sched/core.c:2704:20: warning: unused function 'is_migration_disabled'
static inline bool is_migration_disabled(struct task_struct
^
>> kernel/sched/core.c:2709:20: warning: unused function 'rq_has_pinned_tasks'
static inline bool rq_has_pinned_tasks(struct rq
^
kernel/sched/core.c:4496:20: warning: unused function 'sched_tick_start'
static inline void sched_tick_start(int cpu) { }
^
kernel/sched/core.c:4497:20: warning: unused function 'sched_tick_stop'
static inline void sched_tick_stop(int cpu) { }
^
fatal error: error in backend: Nested variants found in inline asm string: '
.set push
.set noat
.set push
.set arch=r4000
.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/cmpxchg.h",
.line = 163, $); 0x00 ) != -1)) : $))) ) && ( 0 ); .set push; .set mips64r2;
.rept 1; sync 0x00; .endr; .set pop; .else; ; .endif
1: ll $0, $2 # __cmpxchg_asm
bne $0, ${3:z}, 2f
.set pop
move $$1, ${4:z}
.set arch=r4000
sc $$1, $1
beqz $$1, 1b
.set pop
2: .if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct
ftrace_branch_data __attribute__((__aligned__(4)))
__attribute__((__section__("_ftrace_branch"))) __if_trace = $( .func =
__func__, .file = "arch/mips/include/asm/cmpxchg.h", .line = 163, $); 0x00 ) !=
-1)) : $))) ) && ( 0 ); .set push; .set mips64r2; .rept 1; sync 0x00; .endr;
.set pop; .else; ; .endif
'
clang-12: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 12.0.0 (git://gitmirror/llvm_project
22b68440e1647e16b5ee24b924986207173c02d1)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-22b68440e1/bin
clang-12: note: diagnostic msg:
Makefile arch block drivers include kernel mm scripts source usr
vim +/rq_has_pinned_tasks +2709 kernel/sched/core.c
2708
> 2709 static inline bool rq_has_pinned_tasks(struct rq *rq)
2710 {
2711 return false;
2712 }
2713
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] usemem: Remove the duplicate do_access
From: Hui Zhu
Got following error when build usemem:
gcc -O -c -Wall -g usemem.c -o usemem.o
usemem.c:451:15: error: redefinition of ‘do_access’
unsigned long do_access(unsigned long *p, unsigned long idx, int read)
^
usemem.c:332:15: note: previous definition of ‘do_access’ was here
unsigned long do_access(unsigned long *p, unsigned long idx, int read)
^
make: *** [usemem.o] Error 1
Remove the duplicate do_access to fix this error.
Signed-off-by: Hui Zhu
---
usemem.c | 12
1 file changed, 12 deletions(-)
diff --git a/usemem.c b/usemem.c
index 48c3d65..e2c46ec 100644
--- a/usemem.c
+++ b/usemem.c
@@ -329,18 +329,6 @@ void detach(void)
}
}
-unsigned long do_access(unsigned long *p, unsigned long idx, int read)
-{
- volatile unsigned long *vp = p;
-
- if (read)
- return vp[idx]; /* read data */
- else {
- vp[idx] = idx; /* write data */
- return 0;
- }
-}
-
unsigned long * allocate(unsigned long bytes)
{
unsigned long *p;
--
1.8.3.1
[PATCH] dt-bindings: usb: Add ranges and dma-coherent property
Add ranges and dma-coherent property in ti,j721e-usb dt-binding.
Signed-off-by: Aswath Govindraju
---
Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
index 4423f0a29f54..0c553e72d2ff 100644
--- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
@@ -38,6 +38,8 @@ properties:
- const: ref
- const: lpm
+ ranges: true
+
ti,usb2-only:
description:
If present, it restricts the controller to USB2.0 mode of
@@ -63,6 +65,8 @@ properties:
'#size-cells':
const: 2
+ dma-coherent: true
+
patternProperties:
"^usb@":
type: object
@@ -73,6 +77,7 @@ required:
- power-domains
- clocks
- clock-names
+ - ranges
additionalProperties: false
@@ -95,6 +100,7 @@ examples:
assigned-clock-parents = <_clks 288 16>; /* HFOSC0 */
#address-cells = <2>;
#size-cells = <2>;
+ranges;
usb@600 {
compatible = "cdns,usb3";
--
2.17.1
[RFC PATCH 02/37] fs: use bio_init_fields in block_dev
Signed-off-by: Chaitanya Kulkarni
---
fs/block_dev.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 3e5b02f6606c..44b992976ee5 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -239,12 +239,9 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct
iov_iter *iter,
}
bio_init(, vecs, nr_pages);
- bio_set_dev(, bdev);
- bio.bi_iter.bi_sector = pos >> 9;
- bio.bi_write_hint = iocb->ki_hint;
- bio.bi_private = current;
- bio.bi_end_io = blkdev_bio_end_io_simple;
- bio.bi_ioprio = iocb->ki_ioprio;
+ bio_init_fields(, bdev, pos >> 9, current, blkdev_bio_end_io_simple,
+ iocb->ki_ioprio, iocb->ki_hint);
+
ret = bio_iov_iter_get_pages(, iter);
if (unlikely(ret))
@@ -390,12 +387,8 @@ __blkdev_direct_IO(struct kiocb *iocb, struct iov_iter
*iter, int nr_pages)
blk_start_plug();
for (;;) {
- bio_set_dev(bio, bdev);
- bio->bi_iter.bi_sector = pos >> 9;
- bio->bi_write_hint = iocb->ki_hint;
- bio->bi_private = dio;
- bio->bi_end_io = blkdev_bio_end_io;
- bio->bi_ioprio = iocb->ki_ioprio;
+ bio_init_fields(bio, bdev, pos >> 9, dio, blkdev_bio_end_io,
+ iocb->ki_ioprio, iocb->ki_hint);
ret = bio_iov_iter_get_pages(bio, iter);
if (unlikely(ret)) {
--
2.22.1
[PATCH] x86/cpu/zhaoxin: Fix wrong lowercase naming
This is printed during kernel boot, match it with other supported x86 cpus.
[0.00] KERNEL supported cpus:
[0.00] Intel GenuineIntel
[0.00] AMD AuthenticAMD
[0.00] Hygon HygonGenuine
[0.00] Centaur CentaurHauls
[0.00] zhaoxin Shanghai
Keep identification string match with CPUID.
Signed-off-by: Isaac Chen
---
arch/x86/kernel/cpu/zhaoxin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
index 05fa4ef63490..77c33ed80a67 100644
--- a/arch/x86/kernel/cpu/zhaoxin.c
+++ b/arch/x86/kernel/cpu/zhaoxin.c
@@ -120,7 +120,7 @@ zhaoxin_size_cache(struct cpuinfo_x86 *c, unsigned int size)
#endif
static const struct cpu_dev zhaoxin_cpu_dev = {
- .c_vendor = "zhaoxin",
+ .c_vendor = "Zhaoxin",
.c_ident= { " Shanghai " },
.c_early_init = early_init_zhaoxin,
.c_init = init_zhaoxin,
--
2.27.0
Re: [PATCH 12/22] perf daemon: Allow only one daemon over base directory
On Sun, Jan 3, 2021 at 7:05 AM Jiri Olsa wrote:
>
> Add 'lock' file under daemon base and flock it, so only one
> perf daemon can run on top of it.
>
> Example:
>
> # cat ~/.perfconfig
> [daemon]
> base=/opt/perfdata
>
> [session-cycles]
> run = -m 10M -e cycles --overwrite --switch-output -a
>
> [session-sched]
> run = -m 20M -e sched:* --overwrite --switch-output -a
>
> Starting the daemon:
>
> # perf daemon start
>
> And try once more:
>
> # perf daemon start
> failed: another perf daemon (pid 775594) owns /opt/perfdata
>
> will end up with an error, because there's already one running
> on top of /opt/perfdata.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/builtin-daemon.c | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c
> index 45748bb471ec..1982eedd3f3f 100644
> --- a/tools/perf/builtin-daemon.c
> +++ b/tools/perf/builtin-daemon.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -562,12 +563,18 @@ static int cmd_session_list(struct daemon *daemon,
> union cmd *cmd, FILE *out)
> /* output */
> csv_sep, daemon->base, SESSION_OUTPUT);
>
> + fprintf(out, "%c%s/%s",
> + /* lock */
> + csv_sep, daemon->base, "lock");
> +
> fprintf(out, "\n");
> } else {
> fprintf(out, "[%d:daemon] base: %s\n", getpid(),
> daemon->base);
> if (cmd->list.verbose) {
> fprintf(out, " output: %s/%s\n",
> daemon->base, SESSION_OUTPUT);
> + fprintf(out, " lock:%s/lock\n",
> + daemon->base);
> }
> }
>
> @@ -761,6 +768,42 @@ static int handle_config_changes(struct daemon *daemon,
> int conf_fd,
> return 0;
> }
>
> +static int check_lock(struct daemon *daemon)
> +{
> + char path[PATH_MAX];
> + char buf[20];
> + int fd, pid;
> + ssize_t len;
> +
> + scnprintf(path, sizeof(path), "%s/lock", daemon->base);
> +
> + fd = open(path, O_RDWR|O_CREAT|O_CLOEXEC, 0640);
> + if (fd < 0)
> + return -1;
> +
> + if (lockf(fd, F_TLOCK, 0) < 0) {
> + filename__read_int(path, );
> + fprintf(stderr, "failed: another perf daemon (pid %d) owns
> %s\n",
> + pid, daemon->base);
> + return -1;
> + }
So the fd is (a kind of) leaked and the lock is released only when
the daemon is going to die, right?
Thanks,
Namhyung
> +
> + scnprintf(buf, sizeof(buf), "%d", getpid());
> + len = strlen(buf);
> +
> + if (write(fd, buf, len) != len) {
> + perror("write failed");
> + return -1;
> + }
> +
> + if (ftruncate(fd, len)) {
> + perror("ftruncate failed");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> static int go_background(struct daemon *daemon)
> {
> int pid, fd;
> @@ -775,6 +818,9 @@ static int go_background(struct daemon *daemon)
> if (setsid() < 0)
> return -1;
>
> + if (check_lock(daemon))
> + return -1;
> +
> umask(0);
>
> if (chdir(daemon->base)) {
> @@ -861,6 +907,9 @@ static int __cmd_start(struct daemon *daemon, struct
> option parent_options[],
> if (setup_server_config(daemon))
> return -1;
>
> + if (foreground && check_lock(daemon))
> + return -1;
> +
> if (!foreground && go_background(daemon))
> return -1;
>
> --
> 2.26.2
>
[RFC PATCH 05/37] ext4: use bio_init_fields in page_io
Signed-off-by: Chaitanya Kulkarni --- fs/ext4/page-io.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c index 03a44a0de86a..53a79a7aac15 100644 --- a/fs/ext4/page-io.c +++ b/fs/ext4/page-io.c @@ -400,10 +400,8 @@ static void io_submit_init_bio(struct ext4_io_submit *io, */ bio = bio_alloc(GFP_NOIO, BIO_MAX_PAGES); fscrypt_set_bio_crypt_ctx_bh(bio, bh, GFP_NOIO); - bio->bi_iter.bi_sector = bh->b_blocknr * (bh->b_size >> 9); - bio_set_dev(bio, bh->b_bdev); - bio->bi_end_io = ext4_end_bio; - bio->bi_private = ext4_get_io_end(io->io_end); + bio_init_fields(bio, bh->b_bdev, bh->b_blocknr * (bh->b_size >> 9), + ext4_get_io_end(io->io_end), ext4_end_bio, 0, 0); io->io_bio = bio; io->io_next_block = bh->b_blocknr; wbc_init_bio(io->io_wbc, bio); -- 2.22.1
Re: [PATCH v2 6/7] platform: x86: Add intel_skl_int3472 driver
Hi Daniel,
On Tue, Jan 19, 2021 at 12:11:40AM +, Daniel Scally wrote:
> On 18/01/2021 21:19, Daniel Scally wrote:
> +static const struct clk_ops skl_int3472_clock_ops = {
> +.prepare = skl_int3472_clk_prepare,
> +.unprepare = skl_int3472_clk_unprepare,
> +.enable = skl_int3472_clk_enable,
> +.disable = skl_int3472_clk_disable,
> +};
> >>
> >> Yeah, sounds like reinventing clk-gpio.c.
> >>
> >> static const struct clk_ops clk_gpio_gate_ops = {
> >>.enable = clk_gpio_gate_enable,
> >>.disable = clk_gpio_gate_disable,
> >>.is_enabled = clk_gpio_gate_is_enabled,
> >> };
> >>
> >> (Or is it mux? It has support there as well.
> >>
> > Hmm, yeah, this looks like it would work actually. So I think I'd need to:
> >
> > 1. Make enabling INTEL_SKL_INT3472 also enable the clk-gpio driver
> >
> > 2. Register a platform device to bind to the clk-gpio driver
> >
> > 3. Register a gpio lookup table so that the clk-gpio driver can find the
> > gpio in question using gpiod_get()
> >
> > And that looks like it will work; I'll try it.
>
> I'm more and more confident that this will work, but it has some
> knock-on effects:
>
> The both clk and regulator gpio driver expects to be able to fetch the
> GPIO using devm_gpiod_get(>dev, "enable", ...). That won't work of
> course, so we need to add another GPIO lookup table so those drivers can
> see the GPIOs. For that, we need to know what dev_name(>dev) will
> be so we can set the .dev_id member of a gpiod_lookup_table to that
> value, but that isn't set until _after_ the pdev is registered (because
> it has to figure out the id, we can't manually set the IDs because there
> could be more than one instance of int3472-discrete bound to multiple
> PMIC devices, and we don't know which id the current one should have).
> Finally, we can't wait until the device is registered because it
> immediately probes, can't find the GPIO and then fails probe.
>
> It's similar problem that causes us to need the i2c-acpi name format
> macros, but complicated by the dynamic ID part of dev_name(>dev)
>
> Solving it is a bit of a sticky one; perhaps something like moving the
> dev_set_name() part of platform_device_add() [1] to its own function,
> that's called in both platform_device_alloc() and
> platform_device_register(). That way it would be available before the
> device itself was registered, meaning we could create the lookup table
> before it probes the driver.
>
> (also, Laurent, if we did it this way we wouldn't be able to also handle
> the led-indicator GPIO here without some fairly major rework)
Given the additional complexity I don't think it's worth it, your
implementation is fine and code duplication with clk-gpio is minimal.
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L563
--
Regards,
Laurent Pinchart
Re: [PATCH v3 10/12] opp: Support set_opp() customization without requiring to use regulators
On 18-01-21, 21:48, Dmitry Osipenko wrote:
> 18.01.2021 14:44, Viresh Kumar пишет:
> > On 18-01-21, 03:55, Dmitry Osipenko wrote:
> >> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> >> index eefd0b15890c..c98fd2add563 100644
> >> --- a/include/linux/pm_opp.h
> >> +++ b/include/linux/pm_opp.h
> >> @@ -13,6 +13,7 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> struct clk;
> >> @@ -74,6 +75,7 @@ struct dev_pm_opp_info {
> >> * @regulator_count: Number of regulators
> >> * @clk: Pointer to clk
> >> * @dev: Pointer to the struct device
> >> + * @kref: Reference counter
> >> *
> >> * This structure contains all information required for setting an OPP.
> >> */
> >> @@ -85,6 +87,7 @@ struct dev_pm_set_opp_data {
> >>unsigned int regulator_count;
> >>struct clk *clk;
> >>struct device *dev;
> >> + struct kref kref;
> >> };
> >
> > Instead of kref thing, allocate the memory for supplies from
> > dev_pm_opp_set_regulators() and store it in new entries in opp-table
> > and for rest of the data from dev_pm_opp_register_set_opp_helper(), to
> > which you can copy supplies pointers then.
> >
>
> Could you please show a code sample?
Sent a patch to you.
--
viresh
RE: [PATCH 2/2] fpga: Add support for Xilinx DFX AXI Shutdown manager
Hi Moritz,
Thanks for the review.
Please find my response inline.
> -Original Message-
> From: Moritz Fischer
> Sent: Saturday, January 16, 2021 8:28 AM
> To: Nava kishore Manne
> Cc: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal Simek
> ; linux-f...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; git ; chinnikishore...@gmail.com
> Subject: Re: [PATCH 2/2] fpga: Add support for Xilinx DFX AXI Shutdown
> manager
>
> Hi,
>
> On Fri, Jan 15, 2021 at 07:04:31AM +0530, Nava kishore Manne wrote:
> > This patch adds support for Xilinx Dynamic Function eXchange(DFX) AXI
> > shutdown manager IP. It can be used to safely handling the AXI traffic
> > on a Reconfigurable Partition when it is undergoing dynamic
> > reconfiguration and there by preventing system deadlock that may occur
> > if AXI transactions are interrupted during reconfiguration.
> >
> > PR-Decoupler and AXI shutdown manager are completely different IPs.
> > But both the IP registers are compatible and also both belong to the
> > same sub-system (fpga-bridge).So using same driver for both IP's.
>
> I'm a bit confused, the whole goal here is to give the thing a different name?
Both the PR Decoupler and AXI Shutdown IP manager IP's are follows same
register spec.
Most of the code is common so we thought of reusing same driver for AXI
shutdown manager as well.
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > drivers/fpga/xilinx-pr-decoupler.c | 35
> > ++
> > 1 file changed, 31 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/fpga/xilinx-pr-decoupler.c
> > b/drivers/fpga/xilinx-pr-decoupler.c
> > index 7d69af230567..c95f3d065ccb 100644
> > --- a/drivers/fpga/xilinx-pr-decoupler.c
> > +++ b/drivers/fpga/xilinx-pr-decoupler.c
> > @@ -19,10 +19,15 @@
> > #define CTRL_OFFSET0
> >
> > struct xlnx_pr_decoupler_data {
> > + const struct xlnx_config_data *ipconfig;
> > void __iomem *io_base;
> > struct clk *clk;
> > };
> >
> > +struct xlnx_config_data {
> > + char *name;
> > +};
> > +
> > static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data
> *d,
> >u32 offset, u32 val)
> > {
> > @@ -76,15 +81,28 @@ static const struct fpga_bridge_ops
> xlnx_pr_decoupler_br_ops = {
> > .enable_show = xlnx_pr_decoupler_enable_show, };
> >
> > +static const struct xlnx_config_data decoupler_config = {
> > + .name = "Xilinx PR Decoupler",
> > +};
> > +
> > +static const struct xlnx_config_data shutdown_config = {
> > + .name = "Xilinx DFX AXI shutdown mgr", };
>
> If it's just the strings, why not store them as is?
In order to differentiate the IP's at probe time we are using this name filed.
> > +
> > static const struct of_device_id xlnx_pr_decoupler_of_match[] = {
> > - { .compatible = "xlnx,pr-decoupler-1.00", },
> > - { .compatible = "xlnx,pr-decoupler", },
> > + { .compatible = "xlnx,pr-decoupler-1.00", .data = _config
> },
> > + { .compatible = "xlnx,pr-decoupler", .data = _config },
> > + { .compatible = "xlnx,dfx-axi-shutdown-manager-1.00",
> > + .data = _config },
> > + { .compatible = "xlnx,dfx-axi-shutdown-manager",
> > + .data = _config },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, xlnx_pr_decoupler_of_match);
> >
> > static int xlnx_pr_decoupler_probe(struct platform_device *pdev) {
> > + struct device_node *np = pdev->dev.of_node;
> > struct xlnx_pr_decoupler_data *priv;
> > struct fpga_bridge *br;
> > int err;
> > @@ -94,6 +112,14 @@ static int xlnx_pr_decoupler_probe(struct
> platform_device *pdev)
> > if (!priv)
> > return -ENOMEM;
> >
> > + if (np) {
> > + const struct of_device_id *match;
> > +
> > + match = of_match_node(xlnx_pr_decoupler_of_match, np);
> > + if (match && match->data)
> > + priv->ipconfig = match->data;
> > + }
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > priv->io_base = devm_ioremap_resource(>dev, res);
> > if (IS_ERR(priv->io_base))
> > @@ -114,7 +140,7 @@ static int xlnx_pr_decoupler_probe(struct
> > platform_device *pdev)
> >
> > clk_disable(priv->clk);
> >
> > - br = devm_fpga_bridge_create(>dev, "Xilinx PR Decoupler",
> > + br = devm_fpga_bridge_create(>dev, priv->ipconfig->name,
> > _pr_decoupler_br_ops, priv);
> > if (!br) {
> > err = -ENOMEM;
> > @@ -125,7 +151,8 @@ static int xlnx_pr_decoupler_probe(struct
> > platform_device *pdev)
> >
> > err = fpga_bridge_register(br);
> > if (err) {
> > - dev_err(>dev, "unable to register Xilinx PR
> Decoupler");
> > + dev_err(>dev, "unable to register %s",
> > + priv->ipconfig->name);
> > goto err_clk;
> > }
> >
> >
[PATCH] opp: Prepare for ->set_opp() helper to work without regulators
Until now the ->set_opp() helper (i.e. special implementation for
setting the OPPs for platforms) was implemented only to take care of
multiple regulators case, but going forward we would need that for other
use cases as well.
This patch prepares for that by allocating the regulator specific part
from dev_pm_opp_set_regulators() and the opp helper part from
dev_pm_opp_register_set_opp_helper().
Signed-off-by: Viresh Kumar
---
Dmitry,
I haven't tested this patch, can you please help with that ?
drivers/opp/core.c | 81 --
drivers/opp/opp.h | 2 ++
2 files changed, 45 insertions(+), 38 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index b1a2296f3065..f80b6f1ca108 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1817,38 +1817,6 @@ void dev_pm_opp_put_prop_name(struct opp_table
*opp_table)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_put_prop_name);
-static int _allocate_set_opp_data(struct opp_table *opp_table)
-{
- struct dev_pm_set_opp_data *data;
- int len, count = opp_table->regulator_count;
-
- if (WARN_ON(!opp_table->regulators))
- return -EINVAL;
-
- /* space for set_opp_data */
- len = sizeof(*data);
-
- /* space for old_opp.supplies and new_opp.supplies */
- len += 2 * sizeof(struct dev_pm_opp_supply) * count;
-
- data = kzalloc(len, GFP_KERNEL);
- if (!data)
- return -ENOMEM;
-
- data->old_opp.supplies = (void *)(data + 1);
- data->new_opp.supplies = data->old_opp.supplies + count;
-
- opp_table->set_opp_data = data;
-
- return 0;
-}
-
-static void _free_set_opp_data(struct opp_table *opp_table)
-{
- kfree(opp_table->set_opp_data);
- opp_table->set_opp_data = NULL;
-}
-
/**
* dev_pm_opp_set_regulators() - Set regulator names for the device
* @dev: Device for which regulator name is being set.
@@ -1865,6 +1833,8 @@ struct opp_table *dev_pm_opp_set_regulators(struct device
*dev,
const char * const names[],
unsigned int count)
{
+ struct dev_pm_opp_supply *supplies;
+ struct dev_pm_set_opp_data *data;
struct opp_table *opp_table;
struct regulator *reg;
int ret, i;
@@ -1906,10 +1876,20 @@ struct opp_table *dev_pm_opp_set_regulators(struct
device *dev,
opp_table->regulator_count = count;
- /* Allocate block only once to pass to set_opp() routines */
- ret = _allocate_set_opp_data(opp_table);
- if (ret)
+ supplies = kmalloc_array(count * 2, sizeof(*supplies), GFP_KERNEL);
+ if (!supplies) {
+ ret = -ENOMEM;
goto free_regulators;
+ }
+
+ mutex_lock(_table->lock);
+ opp_table->sod_supplies = supplies;
+ if (opp_table->set_opp_data) {
+ data = opp_table->set_opp_data;
+ data->old_opp.supplies = supplies;
+ data->new_opp.supplies = supplies + count;
+ }
+ mutex_unlock(_table->lock);
return opp_table;
@@ -1952,9 +1932,16 @@ void dev_pm_opp_put_regulators(struct opp_table
*opp_table)
for (i = opp_table->regulator_count - 1; i >= 0; i--)
regulator_put(opp_table->regulators[i]);
- _free_set_opp_data(opp_table);
+ mutex_lock(_table->lock);
+ if (opp_table->sod_supplies) {
+ opp_table->set_opp_data->old_opp.supplies = NULL;
+ opp_table->set_opp_data->new_opp.supplies = NULL;
+ }
+ mutex_unlock(_table->lock);
+ kfree(opp_table->sod_supplies);
kfree(opp_table->regulators);
+ opp_table->sod_supplies = NULL;
opp_table->regulators = NULL;
opp_table->regulator_count = -1;
@@ -2046,6 +2033,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_put_clkname);
struct opp_table *dev_pm_opp_register_set_opp_helper(struct device *dev,
int (*set_opp)(struct dev_pm_set_opp_data *data))
{
+ struct dev_pm_set_opp_data *data;
struct opp_table *opp_table;
if (!set_opp)
@@ -2062,8 +2050,23 @@ struct opp_table
*dev_pm_opp_register_set_opp_helper(struct device *dev,
}
/* Another CPU that shares the OPP table has set the helper ? */
- if (!opp_table->set_opp)
- opp_table->set_opp = set_opp;
+ if (opp_table->set_opp)
+ return opp_table;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+
+ mutex_lock(_table->lock);
+ opp_table->set_opp_data = data;
+ if (opp_table->sod_supplies) {
+ data->old_opp.supplies = opp_table->sod_supplies;
+ data->new_opp.supplies = opp_table->sod_supplies +
+opp_table->regulator_count;
+ }
+ mutex_unlock(_table->lock);
+
+ opp_table->set_opp = set_opp;
Re: [PATCH RESEND V11 3/7] fuse: Definitions and ioctl for passthrough
On Mon, Jan 18, 2021 at 9:28 PM Alessio Balsini wrote:
>
> Expose the FUSE_PASSTHROUGH interface to user space and declare all the
> basic data structures and functions as the skeleton on top of which the
> FUSE passthrough functionality will be built.
>
> As part of this, introduce the new FUSE passthrough ioctl(), which
> allows the FUSE daemon to specify a direct connection between a FUSE
> file and a lower file system file. Such ioctl() requires users pace to
> pass the file descriptor of one of its opened files through the
> fuse_passthrough_out data structure introduced in this patch. This
> structure includes extra fields for possible future extensions.
> Also, add the passthrough functions for the set-up and tear-down of the
> data structures and locks that will be used both when fuse_conns and
> fuse_files are created/deleted.
>
> Signed-off-by: Alessio Balsini
> ---
[...]
> @@ -699,6 +700,7 @@ void fuse_conn_init(struct fuse_conn *fc, struct
> fuse_mount *fm,
> INIT_LIST_HEAD(>bg_queue);
> INIT_LIST_HEAD(>entry);
> INIT_LIST_HEAD(>devices);
> + idr_init(>passthrough_req);
> atomic_set(>num_waiting, 0);
> fc->max_background = FUSE_DEFAULT_MAX_BACKGROUND;
> fc->congestion_threshold = FUSE_DEFAULT_CONGESTION_THRESHOLD;
> @@ -1052,6 +1054,12 @@ static void process_init_reply(struct fuse_mount *fm,
> struct fuse_args *args,
> fc->handle_killpriv_v2 = 1;
> fm->sb->s_flags |= SB_NOSEC;
> }
> + if (arg->flags & FUSE_PASSTHROUGH) {
> + fc->passthrough = 1;
> + /* Prevent further stacking */
> + fm->sb->s_stack_depth =
> + FILESYSTEM_MAX_STACK_DEPTH + 1;
> + }
Hi Allesio,
I'm sorry I missed the discussion on v10 patch, but this looks wrong.
First of all, assigning a value above a declared MAX_ is misleading
and setting a trap for someone else to trip in the future.
While this may be just a semantic mistake, the code that checks for
(passthrough_sb->s_stack_depth > FILESYSTEM_MAX_STACK_DEPTH)
is just cheating.
fuse_file_{read,write}_iter are stacked operations, no different in any way
than overlayfs and ecryptfs stacked file operations.
Peng Tao mentioned a case of passthrough to overlayfs over ecryptfs [1].
If anyone really thinks this use case is interesting enough (I doubt it), then
they may propose to bump up FILESYSTEM_MAX_STACK_DEPTH to 3,
but not to cheat around the currently defined maximum.
So please set s_max_depth to FILESYSTEM_MAX_STACK_DEPTH and
restore your v10 check of
passthrough_sb->s_stack_depth >= FILESYSTEM_MAX_STACK_DEPTH
Your commit message sounds as if the only purpose of this check is to
prevent stacking of FUSE passthrough on top of each other, but that
is not enough.
Thanks,
Amir.
[1]
https://lore.kernel.org/linux-fsdevel/CA+a=yy6s9spmlr9bqyo1qvu52iaaxu3i9evtb81snrzjkcw...@mail.gmail.com/
[PATCH v2] rtlwifi: rtl8192se: Simplify bool comparison.
Fix the follow coccicheck warnings: ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27: WARNING: Comparison of 0/1 to bool variable. ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26: WARNING: Comparison of 0/1 to bool variable. Reported-by: Abaci Robot Signed-off-by: Jiapeng Zhong --- Changes in v2: -Modified subject. drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c index 47fabce..aff8ab0 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c @@ -1373,7 +1373,7 @@ static void _rtl92se_gen_refreshledstate(struct ieee80211_hw *hw) struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw)); struct rtl_led *pled0 = >ledctl.sw_led0; - if (rtlpci->up_first_time == 1) + if (rtlpci->up_first_time) return; if (rtlpriv->psc.rfoff_reason == RF_CHANGE_BY_IPS) @@ -2302,7 +2302,7 @@ bool rtl92se_gpio_radio_on_off_checking(struct ieee80211_hw *hw, u8 *valid) bool turnonbypowerdomain = false; /* just 8191se can check gpio before firstup, 92c/92d have fixed it */ - if ((rtlpci->up_first_time == 1) || (rtlpci->being_init_adapter)) + if (rtlpci->up_first_time || rtlpci->being_init_adapter) return false; if (ppsc->swrf_processing) -- 1.8.3.1
[PATCH] pinctrl: sunxi: fix use-after-free in sunxi_pmx_free()
When CONFIG_REGULATOR is not set, sunxi_pmx_request() always return
success. Even a group of pins call sunxi_pmx_request(), the refcount
is only 1. This can cause a use-after-free warning in sunxi_pmx_free().
To solve this problem, go to err path if regulator_get() return NULL
or error.
Signed-off-by: Liu Xiang
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index dc8d39ae0..d1a8974eb 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -777,7 +777,7 @@ static int sunxi_pmx_request(struct pinctrl_dev *pctldev,
unsigned offset)
snprintf(supply, sizeof(supply), "vcc-p%c", 'a' + bank);
reg = regulator_get(pctl->dev, supply);
- if (IS_ERR(reg)) {
+ if (IS_ERR_OR_NULL(reg)) {
dev_err(pctl->dev, "Couldn't get bank P%c regulator\n",
'A' + bank);
return PTR_ERR(reg);
@@ -811,7 +811,7 @@ static int sunxi_pmx_free(struct pinctrl_dev *pctldev,
unsigned offset)
PINS_PER_BANK;
struct sunxi_pinctrl_regulator *s_reg = >regulators[bank_offset];
- if (!refcount_dec_and_test(_reg->refcount))
+ if (!s_reg->regulator || !refcount_dec_and_test(_reg->refcount))
return 0;
regulator_disable(s_reg->regulator);
--
2.17.1
Re: [RFC PATCH 01/37] block: introduce bio_init_fields() helper
I don't think a helper just to initialize a few fields is very useful.
But there is something in this area I've wanted to do for a while:
> +static inline void bio_init_fields(struct bio *bio, struct block_device
> *bdev,
> +sector_t sect, void *priv,
> +bio_end_io_t *end_io,
> +unsigned short prio, unsigned short whint)
> +{
> + bio_set_dev(bio, bdev);
> + bio->bi_iter.bi_sector = sect;
> + bio->bi_private = priv;
> + bio->bi_end_io = end_io;
> + bio->bi_ioprio = prio;
> + bio->bi_write_hint = whint;
Ensuring that the device, sector and op are always initialized would
really helper some of the bio mapping helpers, so I'd rather
add a new
struct bio *bio_new(struct block_device *bdev, sector_t sector,
unsigned int op, unsigned int max_bvecs, gfp_t gfp_mask)
helper, where max_bvecs is clamped to BIO_MAX_PAGES.
bi_private, bi_end_io, bi_ioprio and bi_write_hint on the other hand
are purely optional and can be easily set just by the users that care.
arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section `__timer_of_table'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1e2a199f6ccdc15cf111d68d212e2fd4ce65682e commit: 5a17850e251a55bba6d65aefbfeacfa9888cd2cd arm/build: Warn on orphan section placement date: 5 months ago config: arm-randconfig-r013-20210119 (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0 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 # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a17850e251a55bba6d65aefbfeacfa9888cd2cd git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 5a17850e251a55bba6d65aefbfeacfa9888cd2cd # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from >> `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section >> `__timer_of_table' >> arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from >> `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section >> `__timer_of_table' >> arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from >> `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section >> `__timer_of_table' --- 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 v2 6/7] platform: x86: Add intel_skl_int3472 driver
Hi Daniel,
On Mon, Jan 18, 2021 at 08:46:34PM +, Daniel Scally wrote:
> Hi Laurent, thanks for the comments - really appreciate the detail.
>
> Some specific responses below but assume a general "will do" to
> everything you mentioned otherwise...
>
> On 18/01/2021 09:15, Laurent Pinchart wrote:
> >> +PMIC) and one designed for Chrome OS.
> >
> > How about expanding this a bit to explain what the INT3472 stands for ?
> >
> > The INT3472 is an Intel camera power controller, a logical device
> > found on some Skylake-based systems that can map to different
> > hardware devices depending on the platform. On machines
> > designed for Chrome OS, it maps to a TPS68470 camera PMIC. On
> > machines designed for Windows, it maps to either a TP68470
> > camera PMIC, a uP6641Q sensor PMIC, or a set of discrete GPIOs
> > and power gates.
>
> Yeah sure ok
>
> >> This driver handles all three
> >> +situations by discovering information it needs to discern them at
> >> +runtime.
> >> +
> >> +If your device was designed for Chrome OS, this driver will provide
> >> +an ACPI operation region, which must be available before any of the
> >> +devices using this are probed. For this reason, you should select Y
> >> +if your device was designed for ChromeOS. This option also configures
> >> +the designware-i2c driver to be built-in, for the same reason.
> >
> > Is the last sentence a leftover ?
>
> Oops - it is, but it was supposed to remind me to double check that that
> was still necessary. I'll take a look, thanks.
>
> >> +
> >> +#include "intel_skl_int3472_common.h"
> >> +
> >> +int skl_int3472_get_cldb_buffer(struct acpi_device *adev,
> >> + struct int3472_cldb *cldb)
> >> +{
> >> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> >> + acpi_handle handle = adev->handle;
> >> + union acpi_object *obj;
> >> + acpi_status status;
> >> + int ret = 0;
> >> +
> >> + status = acpi_evaluate_object(handle, "CLDB", NULL, );
> >> + if (ACPI_FAILURE(status))
> >> + return -ENODEV;
> >> +
> >> + obj = buffer.pointer;
> >> + if (!obj) {
> >> + dev_err(>dev, "ACPI device has no CLDB object\n");
> >
> > Is this the code path that is taken on Chrome OS ? If so an error
> > message isn't appropriate. I'd drop this message, and instead add an
> > error message in the discrete PMIC code.
>
> Ah yes of course, thanks, I'll move the error message.
>
> >> +
> >> + unsigned int n_gpios; /* how many GPIOs have we seen */
> >> +
> >> + struct int3472_gpio_regulator regulator;
> >> + struct int3472_gpio_clock clock;
> >
> > You don't necessarily need to define separate structures for this, you
> > could also write
> >
> > struct {
> > char regulator_name[GPIO_REGULATOR_NAME_LENGTH];
> > char supply_name[GPIO_REGULATOR_SUPPLY_NAME_LENGTH];
> > struct gpio_desc *gpio;
> > struct regulator_dev *rdev;
> > struct regulator_desc rdesc;
> > } regulator;
> >
> > struct {
> > struct clk *clk;
> > struct clk_hw clk_hw;
> > struct clk_lookup *cl;
> > struct gpio_desc *gpio;
> > } clock;
> >
> > It's entirely up to you.
>
> Ooh yeah I like that more, thanks very much.
>
> >> +/* 79234640-9e10-4fea-a5c1-b5aa8b19756f */
> >> +static const guid_t int3472_gpio_guid =
> >> + GUID_INIT(0x79234640, 0x9e10, 0x4fea,
> >> +0xa5, 0xc1, 0xb5, 0xaa, 0x8b, 0x19, 0x75, 0x6f);
> >> +
> >> +/* 822ace8f-2814-4174-a56b-5f029fe079ee */
> >> +static const guid_t cio2_sensor_module_guid =
> >> + GUID_INIT(0x822ace8f, 0x2814, 0x4174,
> >> +0xa5, 0x6b, 0x5f, 0x02, 0x9f, 0xe0, 0x79, 0xee);
> >
> > A comment that explains what those DSM functions do would be useful for
> > reference. It has taken lots of time to figure it out, let's spare the
> > pain to the next person who tries to understand this :-)
>
> Hah - good point, well made. I'll explain what they're for then.
>
> >> +static int skl_int3472_clk_enable(struct clk_hw *hw)
> >> +{
> >> + struct int3472_gpio_clock *clk = to_int3472_clk(hw);
> >> +
> >> + gpiod_set_value(clk->gpio, 1);
> >
> > The clock enable() and disable() methods are not supposed to sleep,
> > while setting a GPIO value may sleep in the general case. Should this be
> > moved to skl_int3472_clk_prepare() ? Same for skl_int3472_clk_disable()
> > and skl_int3472_clk_unprepare().
>
> I was under the assumption the difference between gpiod_set_value() and
> gpiod_set_value_cansleep() was that gpiod_set_value() _can't_ sleep, but
> actually reading the function's comments it seems it will just complain
> if it turns out it can sleep:
>
> * This function can be called from contexts where we cannot sleep, and will
> * complain if the GPIO chip functions potentially sleep. It doesn't
> complain, on either of my devices, but I guess that can't be guaranteed
Re: linux-next: Fixes tag needs some work in the csky tree
On Mon, Jan 18, 2021 at 5:49 AM Stephen Rothwell wrote:
>
> Hi all,
>
> In commit
>
> 8bfb676492da ("csky: Fix a size determination in gpr_get()")
>
> Fixes tag
>
> Fixes: dcad7854fcce ("sky: switch to ->regset_get()")
>
> has these problem(s):
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h ("%s")'
Sorry for the mistake. Should be
'Fixes: dcad7854fcce ("csky: switch to ->regset_get()")'
not
'Fixes: dcad7854fcce ("sky: switch to ->regset_get()")'
Should I send the patch again with above fix?
Thanks
Zhenzhong
答复: [RFC PATCH v3 1/5] usb: xhci-mtk: improve bandwidth scheduling with multi-TT
HI Chunfeng
请回复谷歌以下三个问题：
Queston: Are there any reasons for doing this? can only one split
packet be scheduled in a u-frame for isochronous out? This looks like overkill.
Answer: We will calculate the number of uframes based on the isoc out
ep maxp. Except for the last uframe, all other consumed bandwidth is 188. But
to be safe, we also count the bandwidth consumed by the last SS as 188.
Queston: same here. It would be much better to understand if you can
provide some counterexamples of schedule that can happen when this bitmap
checking logic is omitted.
Answer: Maybe you are right, it will indeed double check. I will delete
the bandwidth check, and then perform a regression test.
Queston: I guess this is enough to check the bandwidth limit of the
lower speed bus without a bitmap.
Answer: I explained to you last time that ss cannot be overlapped. This
is a hub compatibility issue. Therefore we need bitmap to prevent ss overlap.
BR
yaqii
-邮件原件-
发件人: Ikjoon Jang [mailto:i...@chromium.org]
发送时间: 2021年1月13日 17:44
收件人: Chunfeng Yun (云春峰)
抄送: Yaqii Wu (武亚奇) ; Zhanyong Wang (王战勇)
; Zhanyong Wang ;
linux-...@vger.kernel.org; open list ; Tianping
Fang (方天平) ; moderated list:ARM/Mediatek SoC
support
主题: Re: [RFC PATCH v3 1/5] usb: xhci-mtk: improve bandwidth scheduling with
multi-TT
On Tue, Dec 22, 2020 at 5:35 PM Chunfeng Yun wrote:
>
> From: Zhanyong Wang
>
> After inserted the usb type-c 3.5mm dongle with headset, dmesg showed:
> usb 1-1.1: new full-speed USB device number 5 using xhci-mtk usb
> 1-1.1: New USB device found, idVendor=05ac, idProduct=110a,
> bcdDevice=26.11 usb 1-1.1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3 usb 1-1.1: Product: USB-C to 3.5mm Headphone Jack
> Adapter usb 1-1.1: Manufacturer: Apple, Inc.
> usb 1-1.1: SerialNumber: DWH915501TFJKLTAM xhci-mtk 1120.xhci: Not
> enough bandwidth!
> usb 1-1.1: can't set config #2, error -28
>
> improve low-speed/full-speed INT/ISOC bandwidth scheduling with USB
> muli-TT.
>
> Signed-off-by: Yaqii Wu
> Signed-off-by: Chunfeng Yun
> ---
> v2~v3: no changes
> ---
> drivers/usb/host/xhci-mtk-sch.c | 91 -
> drivers/usb/host/xhci-mtk.h | 8 ++-
> 2 files changed, 84 insertions(+), 15 deletions(-) mode change
> 100644 => 100755 drivers/usb/host/xhci-mtk-sch.c
>
> diff --git a/drivers/usb/host/xhci-mtk-sch.c
> b/drivers/usb/host/xhci-mtk-sch.c old mode 100644 new mode 100755
> index 45c54d56ecbd..94292b9bbc63
> --- a/drivers/usb/host/xhci-mtk-sch.c
> +++ b/drivers/usb/host/xhci-mtk-sch.c
> @@ -383,7 +383,9 @@ static int check_sch_tt(struct usb_device *udev,
> u32 fs_budget_start;
> u32 start_ss, last_ss;
> u32 start_cs, last_cs;
> - int i;
> + u32 num_esit, base;
> + int i, j;
> + u32 tmp;
>
> start_ss = offset % 8;
> fs_budget_start = (start_ss + 1) % 8; @@ -398,10 +400,13 @@
> static int check_sch_tt(struct usb_device *udev,
> if (!(start_ss == 7 || last_ss < 6))
> return -ERANGE;
>
> - for (i = 0; i < sch_ep->cs_count; i++)
> - if (test_bit(offset + i, tt->split_bit_map))
> + for (i = 0; i < sch_ep->cs_count; i++) {
> + if (test_bit(offset + i, tt->ss_bit_map))
> return -ERANGE;
>
> + if (test_bit(offset + i, tt->cs_bit_map))
> + return -ERANGE;
> + }
Are there any reasons for doing this?
Why can only one split packet be scheduled in a u-frame for isochronous out?
This looks like overkill.
> } else {
> u32 cs_count = DIV_ROUND_UP(sch_ep->maxpkt,
> FS_PAYLOAD_MAX);
>
> @@ -428,8 +433,10 @@ static int check_sch_tt(struct usb_device *udev,
> if (cs_count > 7)
> cs_count = 7; /* HW limit */
>
> - for (i = 0; i < cs_count + 2; i++) {
> - if (test_bit(offset + i, tt->split_bit_map))
> + if (test_bit(offset, tt->ss_bit_map))
> + return -ERANGE;
> + for (i = 0; i < cs_count; i++) {
> + if (test_bit(offset + 2 + i, tt->cs_bit_map))
> return -ERANGE;
> }
>
same here. It would be much better to understand if you can provide some
counterexamples of schedule that can happen when this bitmap checking logic is
omitted.
> @@ -445,11 +452,22 @@ static int check_sch_tt(struct usb_device *udev,
> sch_ep->num_budget_microframes = sch_ep->esit;
> }
>
> + num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit;
> + for (i = 0; i < num_esit; i++) {
> + base = sch_ep->offset + i * sch_ep->esit;
> + for (j = 0; j < sch_ep->num_budget_microframes; j++) {
> +
[PATCH v2] clk: aspeed: Fix APLL calculate formula from ast2600-A2
Starting from A2, the A-PLL calculation has changed. Use the
existing formula for A0/A1 and the new formula for A2 onwards.
Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC")
Signed-off-by: Ryan Chen
---
drivers/clk/clk-ast2600.c | 37 +++--
1 file changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/clk-ast2600.c b/drivers/clk/clk-ast2600.c
index bbacaccad554..8933bd1506b3 100644
--- a/drivers/clk/clk-ast2600.c
+++ b/drivers/clk/clk-ast2600.c
@@ -17,7 +17,8 @@
#define ASPEED_G6_NUM_CLKS 71
-#define ASPEED_G6_SILICON_REV 0x004
+#define ASPEED_G6_SILICON_REV 0x014
+#define CHIP_REVISION_ID GENMASK(23, 16)
#define ASPEED_G6_RESET_CTRL 0x040
#define ASPEED_G6_RESET_CTRL2 0x050
@@ -190,18 +191,34 @@ static struct clk_hw *ast2600_calc_pll(const char *name,
u32 val)
static struct clk_hw *ast2600_calc_apll(const char *name, u32 val)
{
unsigned int mult, div;
+ u32 chip_id = readl(scu_g6_base + ASPEED_G6_SILICON_REV);
- if (val & BIT(20)) {
- /* Pass through mode */
- mult = div = 1;
+ if (((chip_id & CHIP_REVISION_ID) >> 16) >= 2) {
+ if (val & BIT(24)) {
+ /* Pass through mode */
+ mult = div = 1;
+ } else {
+ /* F = 25Mhz * [(m + 1) / (n + 1)] / (p + 1) */
+ u32 m = val & 0x1fff;
+ u32 n = (val >> 13) & 0x3f;
+ u32 p = (val >> 19) & 0xf;
+
+ mult = (m + 1);
+ div = (n + 1) * (p + 1);
+ }
} else {
- /* F = 25Mhz * (2-od) * [(m + 2) / (n + 1)] */
- u32 m = (val >> 5) & 0x3f;
- u32 od = (val >> 4) & 0x1;
- u32 n = val & 0xf;
+ if (val & BIT(20)) {
+ /* Pass through mode */
+ mult = div = 1;
+ } else {
+ /* F = 25Mhz * (2-od) * [(m + 2) / (n + 1)] */
+ u32 m = (val >> 5) & 0x3f;
+ u32 od = (val >> 4) & 0x1;
+ u32 n = val & 0xf;
- mult = (2 - od) * (m + 2);
- div = n + 1;
+ mult = (2 - od) * (m + 2);
+ div = n + 1;
+ }
}
return clk_hw_register_fixed_factor(NULL, name, "clkin", 0,
mult, div);
--
2.17.1
RE: [PATCH 2/2] fpga: Add support for Xilinx DFX AXI Shutdown manager
Hi Tom,
Thanks for the review.
Please find my response inline.
> -Original Message-
> From: Tom Rix
> Sent: Friday, January 15, 2021 11:56 PM
> To: Nava kishore Manne ; m...@kernel.org;
> robh...@kernel.org; Michal Simek ; linux-
> f...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: git ; chinnikishore...@gmail.com
> Subject: Re: [PATCH 2/2] fpga: Add support for Xilinx DFX AXI Shutdown
> manager
>
>
> On 1/14/21 5:34 PM, Nava kishore Manne wrote:
> > This patch adds support for Xilinx Dynamic Function eXchange(DFX) AXI
> > shutdown manager IP. It can be used to safely handling the AXI traffic
> > on a Reconfigurable Partition when it is undergoing dynamic
> > reconfiguration and there by preventing system deadlock that may occur
> > if AXI transactions are interrupted during reconfiguration.
> >
> > PR-Decoupler and AXI shutdown manager are completely different IPs.
> > But both the IP registers are compatible and also both belong to the
> > same sub-system (fpga-bridge).So using same driver for both IP's.
> >
> > Signed-off-by: Nava kishore Manne
> > ---
> > drivers/fpga/xilinx-pr-decoupler.c | 35
> > ++
>
> It looks like the copyright is wrong, please review spelling of Xilix
>
> * Copyright (c) 2017, Xilix Inc
>
Will fix in v2.
>
> > 1 file changed, 31 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/fpga/xilinx-pr-decoupler.c
> > b/drivers/fpga/xilinx-pr-decoupler.c
> > index 7d69af230567..c95f3d065ccb 100644
> > --- a/drivers/fpga/xilinx-pr-decoupler.c
> > +++ b/drivers/fpga/xilinx-pr-decoupler.c
> > @@ -19,10 +19,15 @@
> > #define CTRL_OFFSET0
> >
> > struct xlnx_pr_decoupler_data {
> > + const struct xlnx_config_data *ipconfig;
> > void __iomem *io_base;
> > struct clk *clk;
> > };
> >
> > +struct xlnx_config_data {
> > + char *name;
> > +};
>
> Move xlnx_config_data above xlnx_pr_decouple_data.
>
Will fix in v2.
> could you 'const' char *name ?
>
Will fix in v2.
> > +
> > static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data
> *d,
> >u32 offset, u32 val)
> > {
> > @@ -76,15 +81,28 @@ static const struct fpga_bridge_ops
> xlnx_pr_decoupler_br_ops = {
> > .enable_show = xlnx_pr_decoupler_enable_show, };
> >
> > +static const struct xlnx_config_data decoupler_config = {
> > + .name = "Xilinx PR Decoupler",
> > +};
> > +
> > +static const struct xlnx_config_data shutdown_config = {
> > + .name = "Xilinx DFX AXI shutdown mgr",
>
> To be consistent with decoupler name,
>
> shutdown mgr -> Shutdown Manager
>
Will fix in v2.
> > +};
> > +
> > static const struct of_device_id xlnx_pr_decoupler_of_match[] = {
> > - { .compatible = "xlnx,pr-decoupler-1.00", },
> > - { .compatible = "xlnx,pr-decoupler", },
> > + { .compatible = "xlnx,pr-decoupler-1.00", .data = _config
> },
> > + { .compatible = "xlnx,pr-decoupler", .data = _config },
> > + { .compatible = "xlnx,dfx-axi-shutdown-manager-1.00",
> > + .data = _config },
> > + { .compatible = "xlnx,dfx-axi-shutdown-manager",
> > + .data = _config },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, xlnx_pr_decoupler_of_match);
> >
> > static int xlnx_pr_decoupler_probe(struct platform_device *pdev) {
> > + struct device_node *np = pdev->dev.of_node;
> > struct xlnx_pr_decoupler_data *priv;
> > struct fpga_bridge *br;
> > int err;
> > @@ -94,6 +112,14 @@ static int xlnx_pr_decoupler_probe(struct
> platform_device *pdev)
> > if (!priv)
> > return -ENOMEM;
> >
> > + if (np) {
> > + const struct of_device_id *match;
> > +
> > + match = of_match_node(xlnx_pr_decoupler_of_match, np);
> > + if (match && match->data)
> > + priv->ipconfig = match->data;
> > + }
> > +
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > priv->io_base = devm_ioremap_resource(>dev, res);
> > if (IS_ERR(priv->io_base))
> > @@ -114,7 +140,7 @@ static int xlnx_pr_decoupler_probe(struct
> > platform_device *pdev)
> >
> > clk_disable(priv->clk);
> >
> > - br = devm_fpga_bridge_create(>dev, "Xilinx PR Decoupler",
> > + br = devm_fpga_bridge_create(>dev, priv->ipconfig->name,
> > _pr_decoupler_br_ops, priv);
> > if (!br) {
> > err = -ENOMEM;
> > @@ -125,7 +151,8 @@ static int xlnx_pr_decoupler_probe(struct
> > platform_device *pdev)
> >
> > err = fpga_bridge_register(br);
> > if (err) {
> > - dev_err(>dev, "unable to register Xilinx PR
> Decoupler");
> > + dev_err(>dev, "unable to register %s",
> > + priv->ipconfig->name);
> > goto err_clk;
> > }
>
> Look at XILINX_PR_DECOUPLER entry in Kconfig, maybe add something like
>
> help
>
> Say Y to
arch/s390/pci/pci_event.c:101 __zpci_event_availability() error: we previously assumed 'zdev->zbus' could be null (see line 83)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d
commit: 3047766bc6ec9c6bc9ece85b45a41ff401e8d988 s390/pci: fix enabling a
reserved PCI function
config: s390-randconfig-m031-20210114 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
arch/s390/pci/pci_event.c:101 __zpci_event_availability() error: we previously
assumed 'zdev->zbus' could be null (see line 83)
vim +101 arch/s390/pci/pci_event.c
aa3b7c296732b4 Sebastian Ott 2013-12-12 76 static void
__zpci_event_availability(struct zpci_ccdf_avail *ccdf)
cbc0dd1f856b52 Jan Glauber 2012-11-29 77 {
cbc0dd1f856b52 Jan Glauber 2012-11-29 78 struct zpci_dev *zdev =
get_zdev_by_fid(ccdf->fid);
9a99649f2a89fd Sebastian Ott 2016-01-29 79 struct pci_dev *pdev =
NULL;
623bd44d3f277b Sebastian Ott 2017-05-09 80 enum zpci_state state;
d795ddad36cbc8 Sebastian Ott 2013-11-15 81 int ret;
cbc0dd1f856b52 Jan Glauber 2012-11-29 82
05bc1be6db4b26 Pierre Morel2020-03-23 @83 if (zdev && zdev->zbus
&& zdev->zbus->bus)
^^
Can this be NULL?
44510d6fa0c00a Pierre Morel2020-04-22 84 pdev =
pci_get_slot(zdev->zbus->bus, zdev->devfn);
9a99649f2a89fd Sebastian Ott 2016-01-29 85
1f1dcbd4f23bd1 Sebastian Ott 2013-10-22 86 zpci_err("avail
CCDF:\n");
1f1dcbd4f23bd1 Sebastian Ott 2013-10-22 87 zpci_err_hex(ccdf,
sizeof(*ccdf));
cbc0dd1f856b52 Jan Glauber 2012-11-29 88
cbc0dd1f856b52 Jan Glauber 2012-11-29 89 switch (ccdf->pec) {
7fc611ff3ff1a0 Sebastian Ott 2015-06-16 90 case 0x0301: /*
Reserved|Standby -> Configured */
7fc611ff3ff1a0 Sebastian Ott 2015-06-16 91 if (!zdev) {
f606b3ef47c9f8 Pierre Morel2020-03-25 92 ret =
clp_add_pci_device(ccdf->fid, ccdf->fh, 1);
7fc611ff3ff1a0 Sebastian Ott 2015-06-16 93 break;
7fc611ff3ff1a0 Sebastian Ott 2015-06-16 94 }
fcf2f402937a66 Sebastian Ott 2013-12-18 95 zdev->fh =
ccdf->fh;
f606b3ef47c9f8 Pierre Morel2020-03-25 96 zdev->state =
ZPCI_FN_STATE_CONFIGURED;
3047766bc6ec9c Niklas Schnelle 2020-06-18 97 ret =
zpci_enable_device(zdev);
3047766bc6ec9c Niklas Schnelle 2020-06-18 98 if (ret)
3047766bc6ec9c Niklas Schnelle 2020-06-18 99 break;
3047766bc6ec9c Niklas Schnelle 2020-06-18 100
3047766bc6ec9c Niklas Schnelle 2020-06-18 @101 pdev =
pci_scan_single_device(zdev->zbus->bus, zdev->devfn);
^^^
Unchecked dereference
3047766bc6ec9c Niklas Schnelle 2020-06-18 102 if (!pdev)
3047766bc6ec9c Niklas Schnelle 2020-06-18 103 break;
3047766bc6ec9c Niklas Schnelle 2020-06-18 104
3047766bc6ec9c Niklas Schnelle 2020-06-18 105
pci_bus_add_device(pdev);
3047766bc6ec9c Niklas Schnelle 2020-06-18 106
pci_lock_rescan_remove();
3047766bc6ec9c Niklas Schnelle 2020-06-18 107
pci_bus_add_devices(zdev->zbus->bus);
3047766bc6ec9c Niklas Schnelle 2020-06-18 108
pci_unlock_rescan_remove();
cbc0dd1f856b52 Jan Glauber 2012-11-29 109 break;
d795ddad36cbc8 Sebastian Ott 2013-11-15 110 case 0x0302: /*
Reserved -> Standby */
f606b3ef47c9f8 Pierre Morel2020-03-25 111 if (!zdev) {
d795ddad36cbc8 Sebastian Ott 2013-11-15 112
clp_add_pci_device(ccdf->fid, ccdf->fh, 0);
cbc0dd1f856b52 Jan Glauber 2012-11-29 113 break;
f606b3ef47c9f8 Pierre Morel2020-03-25 114 }
f606b3ef47c9f8 Pierre Morel2020-03-25 115 zdev->fh =
ccdf->fh;
f606b3ef47c9f8 Pierre Morel2020-03-25 116 break;
d795ddad36cbc8 Sebastian Ott 2013-11-15 117 case 0x0303: /*
Deconfiguration requested */
623bd44d3f277b Sebastian Ott 2017-05-09 118 if (!zdev)
623bd44d3f277b Sebastian Ott 2017-05-09 119 break;
d795ddad36cbc8 Sebastian Ott 2013-11-15 120 if (pdev)
2a01bd1bd3d28d Sebastian Ott 2015-07-28 121
pci_stop_and_remove_bus_device_locked(pdev);
cbc0dd1f856b52 Jan Glauber 2012-11-29 122
d795ddad36cbc8 Sebastian Ott 2013-11-15 123 ret =
zpci_disable_device(zdev);
d795ddad36cbc8 Sebastian Ott 2013-11-15 124 if (ret)
d795ddad36cbc8 Sebastian Ott
linux-next: build warnings after merge of the jc_docs tree
Hi all, After merging the jc_docs tree, today's linux-next build (KCONFIG_NAME) produced these warnings: fs/pstore/zone.c:39: warning: expecting prototype for struct psz_head. Prototype was for struct psz_buffer instead include/linux/connector.h:122: warning: expecting prototype for cn_netlink_send_mult(). Prototype was for cn_netlink_send() instead include/linux/firmware/intel/stratix10-svc-client.h:15: warning: expecting prototype for Service layer driver supports client names(). Prototype was for SVC_CLIENT_FPGA() instead include/linux/firmware/intel/stratix10-svc-client.h:45: warning: expecting prototype for in bit number(). Prototype was for SVC_STATUS_OK() instead include/linux/firmware/intel/stratix10-svc-client.h:59: warning: expecting prototype for Flag bit for COMMAND_RECONFIG(). Prototype was for COMMAND_RECONFIG_FLAG_PARTIAL() instead include/linux/firmware/intel/stratix10-svc-client.h:66: warning: expecting prototype for Timeout settings for service clients(). Prototype was for SVC_RECONFIG_REQUEST_TIMEOUT_MS() instead include/linux/firmware/intel/stratix10-svc-client.h:228: warning: expecting prototype for intel_svc_done(). Prototype was for stratix10_svc_done() instead include/linux/firmware/intel/stratix10-svc-client.h:15: warning: expecting prototype for Service layer driver supports client names(). Prototype was for SVC_CLIENT_FPGA() instead include/linux/firmware/intel/stratix10-svc-client.h:45: warning: expecting prototype for in bit number(). Prototype was for SVC_STATUS_OK() instead include/linux/firmware/intel/stratix10-svc-client.h:59: warning: expecting prototype for Flag bit for COMMAND_RECONFIG(). Prototype was for COMMAND_RECONFIG_FLAG_PARTIAL() instead include/linux/firmware/intel/stratix10-svc-client.h:66: warning: expecting prototype for Timeout settings for service clients(). Prototype was for SVC_RECONFIG_REQUEST_TIMEOUT_MS() instead include/linux/firmware/intel/stratix10-svc-client.h:228: warning: expecting prototype for intel_svc_done(). Prototype was for stratix10_svc_done() instead include/linux/firmware/intel/stratix10-svc-client.h:15: warning: expecting prototype for Service layer driver supports client names(). Prototype was for SVC_CLIENT_FPGA() instead include/linux/firmware/intel/stratix10-svc-client.h:45: warning: expecting prototype for in bit number(). Prototype was for SVC_STATUS_OK() instead include/linux/firmware/intel/stratix10-svc-client.h:59: warning: expecting prototype for Flag bit for COMMAND_RECONFIG(). Prototype was for COMMAND_RECONFIG_FLAG_PARTIAL() instead include/linux/firmware/intel/stratix10-svc-client.h:66: warning: expecting prototype for Timeout settings for service clients(). Prototype was for SVC_RECONFIG_REQUEST_TIMEOUT_MS() instead include/linux/firmware/intel/stratix10-svc-client.h:228: warning: expecting prototype for intel_svc_done(). Prototype was for stratix10_svc_done() instead include/linux/firmware/intel/stratix10-svc-client.h:15: warning: expecting prototype for Service layer driver supports client names(). Prototype was for SVC_CLIENT_FPGA() instead include/linux/firmware/intel/stratix10-svc-client.h:45: warning: expecting prototype for in bit number(). Prototype was for SVC_STATUS_OK() instead include/linux/firmware/intel/stratix10-svc-client.h:59: warning: expecting prototype for Flag bit for COMMAND_RECONFIG(). Prototype was for COMMAND_RECONFIG_FLAG_PARTIAL() instead include/linux/firmware/intel/stratix10-svc-client.h:66: warning: expecting prototype for Timeout settings for service clients(). Prototype was for SVC_RECONFIG_REQUEST_TIMEOUT_MS() instead include/linux/firmware/intel/stratix10-svc-client.h:228: warning: expecting prototype for intel_svc_done(). Prototype was for stratix10_svc_done() instead include/linux/firmware/intel/stratix10-svc-client.h:15: warning: expecting prototype for Service layer driver supports client names(). Prototype was for SVC_CLIENT_FPGA() instead include/linux/firmware/intel/stratix10-svc-client.h:45: warning: expecting prototype for in bit number(). Prototype was for SVC_STATUS_OK() instead include/linux/firmware/intel/stratix10-svc-client.h:59: warning: expecting prototype for Flag bit for COMMAND_RECONFIG(). Prototype was for COMMAND_RECONFIG_FLAG_PARTIAL() instead include/linux/firmware/intel/stratix10-svc-client.h:66: warning: expecting prototype for Timeout settings for service clients(). Prototype was for SVC_RECONFIG_REQUEST_TIMEOUT_MS() instead include/linux/firmware/intel/stratix10-svc-client.h:228: warning: expecting prototype for intel_svc_done(). Prototype was for stratix10_svc_done() instead include/linux/memblock.h:292: warning: expecting prototype for for_each_free_mem_range_in_zone(). Prototype was for for_each_free_mem_pfn_range_in_zone() instead include/linux/memblock.h:308: warning: expecting prototype for for_each_free_mem_range_in_zone_from(). Prototype was for for_each_free_mem_pfn_range_in_zone_from() instead
RE: [PATCH 1/2] dt-bindings: fpga: Add compatible value for Xilinx DFX AXI shutdown manger
Hi Tom, Thanks for the review. Please find my response inline. > -Original Message- > From: Tom Rix > Sent: Friday, January 15, 2021 11:37 PM > To: Nava kishore Manne ; m...@kernel.org; > robh...@kernel.org; Michal Simek ; linux- > f...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Cc: git ; chinnikishore...@gmail.com > Subject: Re: [PATCH 1/2] dt-bindings: fpga: Add compatible value for Xilinx > DFX AXI shutdown manger > > > On 1/14/21 5:34 PM, Nava kishore Manne wrote: > > This patch Adds compatible value for Xilinx Dynamic Function > > eXchnage(DFX) AXI Shutdown manager IP. > > A multi patch set should have a cover letter. > > Use git format-patch --cover-letter > Will fix in v2. > > Signed-off-by: Nava kishore Manne > > --- > > .../bindings/fpga/xilinx-pr-decoupler.txt | 19 --- > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt > > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt > > index 4284d293fa61..42fca058a5f4 100644 > > --- a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt > > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt > > @@ -7,13 +7,26 @@ changes from passing through the bridge. The > > controller can also couple / enable the bridges which allows traffic > > to pass through the bridge normally. > Below is some wordsmithing to make the compatibility explicit and remove > unneeded words Will fix in v2 > > > > +Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown manager > > +Softcore > is compatible with the Xilinx LogiCORE pr-decoupler. Yes, Both IP's are compatible with respect to the IP registers spec. > > + > > +The Xilinx LogiCORE Dynamic Function eXchange(DFX) AXI shutdown > > +manager manages one or more shutdown managers / fpga bridges. > > +The controller can shutdown/passthrough the bridges which prevents > > Delete 4 lines above. > Will fix in v2. > The DFX AXI shutdown manager prevents > Will fix in v2. > > +AXI traffic from passing through the bridge. The controller safely > > +handles AXI4MM and AXI4-Lite interfaces on a Reconfigurable Partition > > +when it is undergoing dynamic reconfiguration (DFX), preventing > > +system > > I don't know about the use of '(DFX)' here, above it is Dynamic Function > eXchange' > > Here it is dynamic reconfiguration, maybe just delete the '(DFX)' > Will fix in v2. > > +deadlock that can occur if AXI transactions are interrupted by DFX > > + > > The Driver supports only MMIO handling. A PR region can have multiple > > -PR Decouplers which can be handled independently or chained via > > decouple/ -decouple_status signals. > > +PR Decouplers/AXI shutdown manager which can be handled > independently > > +or chained via decouple/ decouple_status signals. > Being compatible, i don't think it is necessary to add to / change this > section. > > > > Required properties: > > - compatible : Should contain "xlnx,pr-decoupler-1.00" > > followed > by > > - "xlnx,pr-decoupler" > > + "xlnx,pr-decoupler" or > > + "xlnx,dfx-axi-shutdown-manager-1.00" followed by > > + "xlnx,dfx-axi-shutdown-manager" > > - regs : base address and size for decoupler module > > - clocks : input clock to IP > > - clock-names : should contain "aclk" > > Adding an example similar to the existing would be helpful. > Will fix in v2. Regards, Navakishore.
RE: [PATCH] Bluetooth: btrtl: Enable WBS for the specific Realtek devices
Hi! Abhishek,
My bad! I should check the code base is the latest and follow it.
I'll submit the v2 patch. Thanks for your review.
BRs,
Max
-Original Message-
From: Abhishek Pandit-Subedi
Sent: Tuesday, January 19, 2021 12:41 PM
To: Max Chou
Cc: Marcel Holtmann ; Johan Hedberg
; Luiz Augusto von Dentz ; Bluez
mailing list ; LKML
; alex...@realsil.com.cn; Hilda Wu
; KidmanLee ; Shyh-In Hwang
Subject: Re: [PATCH] Bluetooth: btrtl: Enable WBS for the specific Realtek
devices
Hi Max,
On Mon, Jan 18, 2021 at 3:28 AM wrote:
>
> From: Max Chou
>
> By this change, it will enable WBS supported on the specific Realtek
> BT devices, such as RTL8822C and RTL8852A.
> In the future, it's able to maintain what the Realtek devices support
> WBS here.
>
> Tested-by: Hilda Wu
> Signed-off-by: Max Chou
> ---
> drivers/bluetooth/btrtl.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> index 24f03a1f8d57..835819c47ae6 100644
> --- a/drivers/bluetooth/btrtl.c
> +++ b/drivers/bluetooth/btrtl.c
> @@ -38,6 +38,19 @@
> .hci_ver = (hciv), \
> .hci_bus = (bus)
>
> +enum btrtl_chip_id {
> + CHIP_ID_8723A, /* index 0 for RTL8723A*/
> + CHIP_ID_8723B, /* index 1 for RTL8723B*/
> + CHIP_ID_8821A, /* index 2 for RTL8821A*/
> + CHIP_ID_8761A, /* index 3 for RTL8761A*/
> + CHIP_ID_8822B = 8, /* index 8 for RTL8822B */
> + CHIP_ID_8723D, /* index 9 for RTL8723D */
> + CHIP_ID_8821C, /* index 10 for RTL8821C */
> + CHIP_ID_8822C = 13, /* index 13 for RTL8822C */
> + CHIP_ID_8761B, /* index 14 for RTL8761B */
> + CHIP_ID_8852A = 18, /* index 18 for RTL8852A */
> +};
> +
> struct id_table {
> __u16 match_flags;
> __u16 lmp_subver;
> @@ -58,6 +71,7 @@ struct btrtl_device_info {
> u8 *cfg_data;
> int cfg_len;
> bool drop_fw;
> + int project_id;
> };
>
> static const struct id_table ic_id_table[] = { @@ -307,8 +321,10 @@
> static int rtlbt_parse_firmware(struct hci_dev *hdev,
>
> /* Find project_id in table */
> for (i = 0; i < ARRAY_SIZE(project_id_to_lmp_subver); i++) {
> - if (project_id == project_id_to_lmp_subver[i].id)
> + if (project_id == project_id_to_lmp_subver[i].id) {
> + btrtl_dev->project_id = project_id;
> break;
> + }
> }
>
> if (i >= ARRAY_SIZE(project_id_to_lmp_subver)) { @@ -725,12
> +741,16 @@ int btrtl_setup_realtek(struct hci_dev *hdev)
> /* Enable central-peripheral role (able to create new connections with
> * an existing connection in slave role).
> */
> - switch (btrtl_dev->ic_info->lmp_subver) {
> - case RTL_ROM_LMP_8822B:
> + /* Enable WBS supported for the specific Realtek devices. */
> + switch (btrtl_dev->project_id) {
> + case CHIP_ID_8822C:
> + case CHIP_ID_8852A:
> set_bit(HCI_QUIRK_VALID_LE_STATES, >quirks);
> + set_bit(HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED,
> + >quirks);
> break;
> default:
> rtl_dev_dbg(hdev, "Central-peripheral role not
> enabled.");
> + rtl_dev_dbg(hdev, "WBS supported not enabled.");
> break;
> }
There is a null-check on btrtl_dev->ic_info right above this switch statement
(https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=b649813eadbc062d8682f7a20aa025275707dd1f).
Is this still necessary with this change? (Sorry, I missed this during our
previous review).
>
> --
> 2.17.1
>
Abhishek
--Please consider the environment before printing this e-mail.
