RE: [PATCH] vdpa/mlx5: Fix erroneous null pointer checks
After all this patch is not fixing it all. If we get to default of the switch
statement we will free invalid pointer so removing ack-ed by me.
The previous patch by Colin King fixes it.
-Original Message-
From: Eli Cohen
Sent: Sunday, August 9, 2020 8:53 AM
To: Alex Dewar
Cc: Michael S. Tsirkin ; Jason Wang ;
Parav Pandit ; virtualizat...@lists.linux-foundation.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vdpa/mlx5: Fix erroneous null pointer checks
Acked-by: Eli Cohen
On Thu, Aug 06, 2020 at 08:18:39PM +0100, Alex Dewar wrote:
> In alloc_inout() in net/mlx5_vnet.c, there are a few places where
> memory is allocated to *in and *out, but only the values of in and out
> are null-checked (i.e. there is a missing dereference). Fix this.
>
> Addresses-Coverity: ("CID 1496603: (REVERSE_INULL)")
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> devices")
> Signed-off-by: Alex Dewar
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 3ec44a4f0e45..bcb6600c2839 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -867,7 +867,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(qp_2rst_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(*outlen, GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(qp_2rst_in, *in, opcode, cmd); @@ -879,7 +879,7 @@
> static
> void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(rst2init_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(rst2init_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(rst2init_qp_in, *in, opcode, cmd); @@ -896,7 +896,7 @@
> static void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int
> *inl
> *outlen = MLX5_ST_SZ_BYTES(init2rtr_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(init2rtr_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(init2rtr_qp_in, *in, opcode, cmd); @@ -914,7 +914,7 @@
> static void alloc_inout(struct mlx5_vdpa_net *ndev, int cmd, void **in, int
> *inl
> *outlen = MLX5_ST_SZ_BYTES(rtr2rts_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(rtr2rts_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(rtr2rts_qp_in, *in, opcode, cmd);
> --
> 2.28.0
>
Re: [PATCH][next] vdpa/mlx5: fix memory allocation failure checks
On Thu, Aug 06, 2020 at 05:08:28PM +0100, Colin King wrote:
Acked by: Eli Cohen
> From: Colin Ian King
>
> The memory allocation failure checking for in and out is currently
> checking if the pointers are valid rather than the contents of what
> they point to. Hence the null check on failed memory allocations is
> incorrect. Fix this by adding the missing indirection in the check.
> Also for the default case, just set the *in and *out to null as
> these don't have any thing allocated to kfree. Finally remove the
> redundant *in and *out check as these have been already done on each
> allocation in the case statement.
>
> Addresses-Coverity: ("Null pointer dereference")
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
> Signed-off-by: Colin Ian King
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index 3ec44a4f0e45..55bc58e1dae9 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -867,7 +867,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(qp_2rst_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(*outlen, GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(qp_2rst_in, *in, opcode, cmd);
> @@ -879,7 +879,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(rst2init_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(rst2init_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(rst2init_qp_in, *in, opcode, cmd);
> @@ -896,7 +896,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(init2rtr_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(init2rtr_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(init2rtr_qp_in, *in, opcode, cmd);
> @@ -914,7 +914,7 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> *outlen = MLX5_ST_SZ_BYTES(rtr2rts_qp_out);
> *in = kzalloc(*inlen, GFP_KERNEL);
> *out = kzalloc(MLX5_ST_SZ_BYTES(rtr2rts_qp_out), GFP_KERNEL);
> - if (!in || !out)
> + if (!*in || !*out)
> goto outerr;
>
> MLX5_SET(rtr2rts_qp_in, *in, opcode, cmd);
> @@ -927,16 +927,15 @@ static void alloc_inout(struct mlx5_vdpa_net *ndev, int
> cmd, void **in, int *inl
> MLX5_SET(qpc, qpc, rnr_retry, 7);
> break;
> default:
> - goto outerr;
> + goto outerr_nullify;
> }
> - if (!*in || !*out)
> - goto outerr;
>
> return;
>
> outerr:
> kfree(*in);
> kfree(*out);
> +outerr_nullify:
> *in = NULL;
> *out = NULL;
> }
> --
> 2.27.0
>
[PATCH] dma-buf.rst: repair length of title underline
With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are
a bad idea"), document generation warns:
Documentation/driver-api/dma-buf.rst:182: \
WARNING: Title underline too short.
Repair length of title underline to remove warning.
Fixes: 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad
idea")
Signed-off-by: Lukas Bulwahn
---
Daniel, please pick this minor non-urgent fix to your new documentation.
Documentation/driver-api/dma-buf.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/dma-buf.rst
b/Documentation/driver-api/dma-buf.rst
index 100bfd227265..13ea0cc0a3fa 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -179,7 +179,7 @@ DMA Fence uABI/Sync File
:internal:
Indefinite DMA Fences
-
+~
At various times _fence with an indefinite time until dma_fence_wait()
finishes have been proposed. Examples include:
--
2.17.1
RE: [PATCH] vdpa/mlx5: Fix pointer math in mlx5_vdpa_get_config()
Acked-by: Eli Cohen
BTW, vdpa_sim has the same bug.
-Original Message-
From: Dan Carpenter
Sent: Saturday, August 8, 2020 12:33 PM
To: Michael S. Tsirkin ; Eli Cohen
Cc: Jason Wang ; Parav Pandit ;
virtualizat...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
kernel-janit...@vger.kernel.org
Subject: [PATCH] vdpa/mlx5: Fix pointer math in mlx5_vdpa_get_config()
There is a pointer math bug here so if "offset" is non-zero then this will copy
memory from beyond the end of the array.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Dan Carpenter
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 3ec44a4f0e45..9d1637cf772e 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1758,7 +1758,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device
*vdev, unsigned int offset,
struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
if (offset + len < sizeof(struct virtio_net_config))
- memcpy(buf, >config + offset, len);
+ memcpy(buf, (u8 *)>config + offset, len);
}
static void mlx5_vdpa_set_config(struct vdpa_device *vdev, unsigned int
offset, const void *buf,
--
2.27.0
Re: [Linux-kernel-mentees] [PATCH net] rds: Prevent kernel-infoleak in rds_notify_queue_get()
On Sat, Aug 08, 2020 at 03:57:33PM -0700, Jack Leadford wrote:
> Hello!
>
> Thanks to Jason for getting this conversation back on track.
>
> Yes: in general, {} or a partial initializer /will/ zero padding bits.
>
> However, there is a bug in some versions of GCC where {} will /not/ zero
> padding bits; actually, Jason's test program in this mail
> https://lore.kernel.org/lkml/20200731143604.gf24...@ziepe.ca/
> has the right ingredients to trigger the bug, but the GCC
> versions used are outside of the bug window. :)
>
> For more details on these cases and more (including said GCC bug), see my
> paper at:
>
> https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2019/october/padding-the-struct-how-a-compiler-optimization-can-disclose-stack-memory/
>
> Hopefully this paper can serve as a helpful reference when these cases are
> encountered in the kernel.
I read the paper and didn't find exact GCC version, only remark that it
was before GCC 7.
So my question, why is this case different from any other GCC bugs?
AFAIK, we don't add kernel code to overcome GCC bugs which exist in
specific versions, which already were fixed.
More on that, this paper talks about specific flow which doesn't exist
in the discussed patch.
Thanks
Re: [PATCH] fix arm64 build with lack of __cpu_logical_map exported
On Sat, Aug 08, 2020 at 07:29:08PM +0100, Catalin Marinas wrote:
> On Sat, Aug 08, 2020 at 05:29:58PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote:
> > > On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > > > index 87e81d29e6fb..b421a4756793 100644
> > > > --- a/arch/arm64/kernel/setup.c
> > > > +++ b/arch/arm64/kernel/setup.c
> > > > @@ -275,6 +275,7 @@ static int __init
> > > > reserve_memblock_reserved_regions(void)
> > > > arch_initcall(reserve_memblock_reserved_regions);
> > > >
> > > > u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> > > > +EXPORT_SYMBOL_GPL(__cpu_logical_map);
> > >
> > > This was still under discussion, Sudeep preferring an alternative in the
> > > driver:
> > >
> > > http://lkml.kernel.org/r/20200727172744.GD8003@bogus
> > > http://lkml.kernel.org/r/20200724131059.GB6521@bogus
> > >
> > > Sumit came with a new diff inline that fixes the driver instead of
> > > exporting the __cpu_logical_map.
> > >
> > > https://lore.kernel.org/linux-arm-kernel/e3a4bc21-c334-4d48-90b5-aab8d1879...@nvidia.com/
> >
> > Ok, but having a broken tree is not nice, how did this survive
> > linux-next testing?
>
> I guess defconfig worked ok since tegra194-cpufreq is not a module so we
> didn't bother much. The fault was reported for allmodconfig but the
> discussion didn't conclude.
>
> > > Sumit, Sudeep, is the above diff sufficient and can it go upstream?
> >
> > Note that MIPS already export this symbol, so perhaps the drivers that
> > need it on that platform should also be fixed the same way?
>
> I push Kefeng's patch to the arm64 for-next/core branch which exports
> cpu_logical_map() as a function. We can revert it later is the Tegra
> driver is fixed.
>
> I'll send Linus a pull request in a bit, once I finish testing the
> branch.
Thanks, I see it's now in Linus's tree so all should be good.
Now to figure out the arm32 build mess...
greg k-h
Re: realpath "No such file or directory" warnings when building
On Sat, Aug 08, 2020 at 01:28:22PM -0700, Rustam Kovhaev wrote: > tags from KBUILD_OUTPUT directory > Reply-To: > > running 'make ARCH=x86_64 COMPILED_SOURCE=1 cscope tags' in > KBUILD_OUTPUT directory produces lots of "No such file or directory" > warnings from realpath > > it seems like commit 4f491bb6ea2a greatly improved tags generation when > COMPILED_SOURCE=1 is set, but should we add "-q" flag for realpath in > all_compiled_sources() or probably it would be better to fix root cause > and make sure that for example we don't try to find objtool sources and > exclude other similar dirs during tags generation? what do you think? > > ... > realpath: special.h: No such file or directory > realpath: warn.h: No such file or directory > realpath: sigchain.c: No such file or directory > realpath: sigchain.h: No such file or directory > realpath: orc_gen.c: No such file or directory > realpath: objtool.c: No such file or directory > ... Care to send a patch for this? thanks, greg k-h
[PATCH] watchdog: pcwd_usb: Avoid GFP_ATOMIC where it is not needed
There is no need to use GFP_ATOMIC here. It is a probe function, no
spinlock is taken and GFP_KERNEL is used just before and just after this
'usb_alloc_coherent()' call.
Signed-off-by: Christophe JAILLET
---
drivers/watchdog/pcwd_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/pcwd_usb.c b/drivers/watchdog/pcwd_usb.c
index 2f44af1831d0..ea67b98ed35d 100644
--- a/drivers/watchdog/pcwd_usb.c
+++ b/drivers/watchdog/pcwd_usb.c
@@ -657,7 +657,7 @@ static int usb_pcwd_probe(struct usb_interface *interface,
/* set up the memory buffer's */
usb_pcwd->intr_buffer = usb_alloc_coherent(udev, usb_pcwd->intr_size,
- GFP_ATOMIC, _pcwd->intr_dma);
+ GFP_KERNEL, _pcwd->intr_dma);
if (!usb_pcwd->intr_buffer) {
pr_err("Out of memory\n");
goto error;
--
2.25.1
Re: [PATCH 1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi
Am 9. August 2020 02:16:59 MESZ schrieb Chun-Kuang Hu : > >I would like to put all device in mt7623.dtsi with some device's >status is "disabled" and change its status in platform dtsi. >I would like to see all device in mt7623.dtsi because of its name. If >you move some device to platform dtsi, we would trace all platform >dtsi to find out how many device in mt7623. One day a new platform >enable different devices, you would reorganize all these platform >dtsi? Ok,then i change the dts-patch from hdmi-series to disable all nodes and enabling them in bpi-r2 dts. Do they need to be in alphabetical order (or any other)? Is the tmds Patch ok? (because review missing) https://patchwork.kernel.org/patch/11700679/ Just to know before reposting series as v5 :) regards Frank
[PATCH 0/4] Infiniband Subsystem: Remove pci-dma-compat wrapper APIs.
Hii Developers, This patch series will replace all the legacy pci-dma-compat wrappers with the dma-mapping APIs directly in the INFINIBAND Subsystem. This task is done through a coccinelle script which is described in each commit message. The changes are compile tested. Thanks, Suraj Upadhyay. Suraj Upadhyay (4): IB/hfi1: Remove pci-dma-compat wrapper APIs IB/mthca: Remove pci-dma-compat wrapper APIs RDMA/qib: Remove pci-dma-compat wrapper APIs RDMA/pvrdma: Remove pci-dma-compat wrapper APIs drivers/infiniband/hw/hfi1/pcie.c | 8 +++ drivers/infiniband/hw/hfi1/user_exp_rcv.c | 13 +-- drivers/infiniband/hw/mthca/mthca_eq.c| 21 + drivers/infiniband/hw/mthca/mthca_main.c | 8 +++ drivers/infiniband/hw/mthca/mthca_memfree.c | 23 +++ drivers/infiniband/hw/qib/qib_file_ops.c | 12 +- drivers/infiniband/hw/qib/qib_init.c | 4 ++-- drivers/infiniband/hw/qib/qib_pcie.c | 8 +++ drivers/infiniband/hw/qib/qib_user_pages.c| 12 +- .../infiniband/hw/vmw_pvrdma/pvrdma_main.c| 6 ++--- 10 files changed, 59 insertions(+), 56 deletions(-) -- 2.17.1
[PATCH] drivers: bluetooth: btintel.c: fixed format issue.
From: argoz1701
Fixed a coding style issue.
Signed-off-by: Daniel West
---
drivers/bluetooth/btintel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
index 5fa5be3c5598..d0512506fa05 100644
--- a/drivers/bluetooth/btintel.c
+++ b/drivers/bluetooth/btintel.c
@@ -29,7 +29,7 @@ int btintel_check_bdaddr(struct hci_dev *hdev)
HCI_INIT_TIMEOUT);
if (IS_ERR(skb)) {
int err = PTR_ERR(skb);
- bt_dev_err(hdev, "Reading Intel device address failed (%d)",
+ bt_dev_err(hdev, "Reading Intel device address failed
(%d)",
err);
return err;
}
--
2.25.1
[PATCH 1/4] IB/hfi1: Remove pci-dma-compat wrapper APIs
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested.
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
- PCI_DMA_NONE
+ DMA_NONE
@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)
@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)
@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)
@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)
Signed-off-by: Suraj Upadhyay
---
drivers/infiniband/hw/hfi1/pcie.c | 8
drivers/infiniband/hw/hfi1/user_exp_rcv.c | 13 ++---
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/pcie.c
b/drivers/infiniband/hw/hfi1/pcie.c
index 18d32f053d26..a2356bfa1485 100644
--- a/drivers/infiniband/hw/hfi1/pcie.c
+++ b/drivers/infiniband/hw/hfi1/pcie.c
@@ -92,21 +92,21 @@ int hfi1_pcie_init(struct hfi1_devdata *dd)
goto bail;
}
- ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+ ret = dma_set_mask(>dev, DMA_BIT_MASK(64));
if (ret) {
/*
* If the 64 bit setup fails, try 32 bit. Some systems
* do not setup 64 bit maps on systems with 2GB or less
* memory installed.
*/
- ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ ret = dma_set_mask(>dev, DMA_BIT_MASK(32));
if (ret) {
dd_dev_err(dd, "Unable to set DMA mask: %d\n", ret);
goto bail;
}
- ret = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
+ ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
} else {
- ret = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+ ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
}
if (ret) {
dd_dev_err(dd, "Unable to set DMA consistent mask: %d\n", ret);
diff --git a/drivers/infiniband/hw/hfi1/user_exp_rcv.c
b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
index f81ca20f4b69..fe737da3d1dc 100644
--- a/drivers/infiniband/hw/hfi1/user_exp_rcv.c
+++ b/drivers/infiniband/hw/hfi1/user_exp_rcv.c
@@ -175,8 +175,8 @@ static void unpin_rcv_pages(struct hfi1_filedata *fd,
struct hfi1_devdata *dd = fd->uctxt->dd;
if (mapped) {
- pci_unmap_single(dd->pcidev, node->dma_addr,
-node->npages * PAGE_SIZE, PCI_DMA_FROMDEVICE);
+ dma_unmap_single(>pcidev->dev, node->dma_addr,
+node->npages * PAGE_SIZE, DMA_FROM_DEVICE);
pages = >pages[idx];
} else {
pages = >pages[idx];
@@ -735,9 +735,8 @@ static int set_rcvarray_entry(struct hfi1_filedata *fd,
if (!node)
return -ENOMEM;
- phys = pci_map_single(dd->pcidev,
- __va(page_to_phys(pages[0])),
- npages * PAGE_SIZE, PCI_DMA_FROMDEVICE);
+ phys = dma_map_single(>pcidev->dev, __va(page_to_phys(pages[0])),
+ npages * PAGE_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(>pcidev->dev, phys)) {
dd_dev_err(dd, "Failed to DMA map Exp
[PATCH] usb: gadget: tegra-xudc: Avoid GFP_ATOMIC where it is not needed
There is no need to use GFP_ATOMIC here. It is a probe function, no spinlock is taken. Signed-off-by: Christophe JAILLET --- drivers/usb/gadget/udc/tegra-xudc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/tegra-xudc.c index d6ff68c06911..9aa4815c1c59 100644 --- a/drivers/usb/gadget/udc/tegra-xudc.c +++ b/drivers/usb/gadget/udc/tegra-xudc.c @@ -3733,7 +3733,7 @@ static int tegra_xudc_probe(struct platform_device *pdev) unsigned int i; int err; - xudc = devm_kzalloc(>dev, sizeof(*xudc), GFP_ATOMIC); + xudc = devm_kzalloc(>dev, sizeof(*xudc), GFP_KERNEL); if (!xudc) return -ENOMEM; -- 2.25.1
[PATCH 2/4] IB/mthca: Remove pci-dma-compat wrapper APIs
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested.
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
- PCI_DMA_NONE
+ DMA_NONE
@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)
@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)
@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)
@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)
Signed-off-by: Suraj Upadhyay
---
drivers/infiniband/hw/mthca/mthca_eq.c | 21 ++-
drivers/infiniband/hw/mthca/mthca_main.c| 8 +++
drivers/infiniband/hw/mthca/mthca_memfree.c | 23 -
3 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_eq.c
b/drivers/infiniband/hw/mthca/mthca_eq.c
index 2cdf686203c1..9f311bd22f72 100644
--- a/drivers/infiniband/hw/mthca/mthca_eq.c
+++ b/drivers/infiniband/hw/mthca/mthca_eq.c
@@ -617,9 +617,9 @@ static void mthca_free_eq(struct mthca_dev *dev,
mthca_free_mr(dev, >mr);
for (i = 0; i < npages; ++i)
- pci_free_consistent(dev->pdev, PAGE_SIZE,
- eq->page_list[i].buf,
- dma_unmap_addr(>page_list[i], mapping));
+ dma_free_coherent(>pdev->dev, PAGE_SIZE,
+ eq->page_list[i].buf,
+ dma_unmap_addr(>page_list[i], mapping));
kfree(eq->page_list);
mthca_free_mailbox(dev, mailbox);
@@ -739,17 +739,18 @@ int mthca_map_eq_icm(struct mthca_dev *dev, u64 icm_virt)
dev->eq_table.icm_page = alloc_page(GFP_HIGHUSER);
if (!dev->eq_table.icm_page)
return -ENOMEM;
- dev->eq_table.icm_dma = pci_map_page(dev->pdev,
dev->eq_table.icm_page, 0,
- PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
- if (pci_dma_mapping_error(dev->pdev, dev->eq_table.icm_dma)) {
+ dev->eq_table.icm_dma = dma_map_page(>pdev->dev,
+ dev->eq_table.icm_page, 0,
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(>pdev->dev, dev->eq_table.icm_dma)) {
__free_page(dev->eq_table.icm_page);
return -ENOMEM;
}
ret = mthca_MAP_ICM_page(dev, dev->eq_table.icm_dma, icm_virt);
if (ret) {
- pci_unmap_page(dev->pdev, dev->eq_table.icm_dma, PAGE_SIZE,
- PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(>pdev->dev, dev->eq_table.icm_dma,
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
__free_page(dev->eq_table.icm_page);
}
@@ -759,8 +760,8 @@ int mthca_map_eq_icm(struct mthca_dev *dev, u64 icm_virt)
void mthca_unmap_eq_icm(struct mthca_dev *dev)
{
mthca_UNMAP_ICM(dev, dev->eq_table.icm_virt, 1);
- pci_unmap_page(dev->pdev, dev->eq_table.icm_dma, PAGE_SIZE,
- PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(>pdev->dev, dev->eq_table.icm_dma, PAGE_SIZE,
+ DMA_BIDIRECTIONAL);
__free_page(dev->eq_table.icm_page);
}
diff --git a/drivers/infiniband/hw/mthca/mthca_main.c
[PATCH 3/4] RDMA/qib: Remove pci-dma-compat wrapper APIs
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested.
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
- PCI_DMA_NONE
+ DMA_NONE
@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)
@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)
@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)
@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)
Signed-off-by: Suraj Upadhyay
---
drivers/infiniband/hw/qib/qib_file_ops.c | 12 ++--
drivers/infiniband/hw/qib/qib_init.c | 4 ++--
drivers/infiniband/hw/qib/qib_pcie.c | 8
drivers/infiniband/hw/qib/qib_user_pages.c | 12 ++--
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_file_ops.c
b/drivers/infiniband/hw/qib/qib_file_ops.c
index ff87a67dd7b7..d36412ace705 100644
--- a/drivers/infiniband/hw/qib/qib_file_ops.c
+++ b/drivers/infiniband/hw/qib/qib_file_ops.c
@@ -429,8 +429,8 @@ static int qib_tid_update(struct qib_ctxtdata *rcd, struct
file *fp,
dd->f_put_tid(dd, [tid],
RCVHQ_RCV_TYPE_EXPECTED,
dd->tidinvalid);
- pci_unmap_page(dd->pcidev, phys, PAGE_SIZE,
- PCI_DMA_FROMDEVICE);
+ dma_unmap_page(>pcidev->dev, phys,
+ PAGE_SIZE, DMA_FROM_DEVICE);
dd->pageshadow[ctxttid + tid] = NULL;
}
}
@@ -544,8 +544,8 @@ static int qib_tid_free(struct qib_ctxtdata *rcd, unsigned
subctxt,
*/
dd->f_put_tid(dd, [tid],
RCVHQ_RCV_TYPE_EXPECTED, dd->tidinvalid);
- pci_unmap_page(dd->pcidev, phys, PAGE_SIZE,
- PCI_DMA_FROMDEVICE);
+ dma_unmap_page(>pcidev->dev, phys, PAGE_SIZE,
+ DMA_FROM_DEVICE);
qib_release_user_pages(, 1);
}
}
@@ -1780,8 +1780,8 @@ static void unlock_expected_tids(struct qib_ctxtdata *rcd)
phys = dd->physshadow[i];
dd->physshadow[i] = dd->tidinvalid;
dd->pageshadow[i] = NULL;
- pci_unmap_page(dd->pcidev, phys, PAGE_SIZE,
- PCI_DMA_FROMDEVICE);
+ dma_unmap_page(>pcidev->dev, phys, PAGE_SIZE,
+ DMA_FROM_DEVICE);
qib_release_user_pages(, 1);
cnt++;
}
diff --git a/drivers/infiniband/hw/qib/qib_init.c
b/drivers/infiniband/hw/qib/qib_init.c
index 43c8ee1f46e0..35cd5b393281 100644
--- a/drivers/infiniband/hw/qib/qib_init.c
+++ b/drivers/infiniband/hw/qib/qib_init.c
@@ -1335,8 +1335,8 @@ static void cleanup_device_data(struct qib_devdata *dd)
for (i = ctxt_tidbase; i < maxtid; i++) {
if (!tmpp[i])
continue;
- pci_unmap_page(dd->pcidev, tmpd[i],
-
[PATCH 4/4] RDMA/pvrdma: Remove pci-dma-compat wrapper APIs
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested.
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
- PCI_DMA_NONE
+ DMA_NONE
@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)
@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)
@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)
@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)
Signed-off-by: Suraj Upadhyay
---
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
index 780fd2dfc07e..3c7802f7e298 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
@@ -839,15 +839,15 @@ static int pvrdma_pci_probe(struct pci_dev *pdev,
}
/* Enable 64-Bit DMA */
- if (pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) == 0) {
- ret = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+ if (dma_set_mask(>dev, DMA_BIT_MASK(64)) == 0) {
+ ret = dma_set_coherent_mask(>dev, DMA_BIT_MASK(64));
if (ret != 0) {
dev_err(>dev,
"pci_set_consistent_dma_mask failed\n");
goto err_free_resource;
}
} else {
- ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ ret = dma_set_mask(>dev, DMA_BIT_MASK(32));
if (ret != 0) {
dev_err(>dev,
"pci_set_dma_mask failed\n");
--
2.17.1
Re: drivers/crypto/sa2ul.c:1349:33: warning: cast from pointer to integer of different size
On Sun, Aug 9, 2020 at 2:49 AM kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
> commit: 2dc53d0047458e28ed05b4548844ba78199857bf crypto: sa2ul - add
> sha1/sha256/sha512 support
> date: 2 weeks ago
> config: m68k-randconfig-r002-20200809 (attached as .config)
> compiler: m68k-linux-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
> git checkout 2dc53d0047458e28ed05b4548844ba78199857bf
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=m68k
>In file included from include/linux/device.h:15,
> from include/linux/dmaengine.h:8,
> from drivers/crypto/sa2ul.c:12:
>drivers/crypto/sa2ul.c: In function 'sa_sha_init':
> >> drivers/crypto/sa2ul.c:1349:33: warning: cast from pointer to integer of
> >> different size [-Wpointer-to-int-cast]
> 1349 | crypto_ahash_digestsize(tfm), (u64)rctx);
> | ^
>include/linux/dev_printk.h:123:47: note: in definition of macro 'dev_dbg'
> 123 | dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
> | ^~~
Fix available since last Tuesday:
https://lore.kernel.org/linux-crypto/20200804092927.7417-1-ge...@linux-m68k.org/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 5/4] RDMA/efa : Remove pci-dma-compat wrapper APIs
The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.
The patch has been generated with the coccinelle script below
and compile-tested.
- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL
- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE
- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE
- PCI_DMA_NONE
+ DMA_NONE
@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)
@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)
@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)
@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)
@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)
@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)
Signed-off-by: Suraj Upadhyay
---
drivers/infiniband/hw/efa/efa_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/efa/efa_main.c
b/drivers/infiniband/hw/efa/efa_main.c
index 92d701146320..bcc931ad71b0 100644
--- a/drivers/infiniband/hw/efa/efa_main.c
+++ b/drivers/infiniband/hw/efa/efa_main.c
@@ -405,13 +405,13 @@ static int efa_device_init(struct efa_com_dev *edev,
struct pci_dev *pdev)
return err;
}
- err = pci_set_dma_mask(pdev, DMA_BIT_MASK(dma_width));
+ err = dma_set_mask(>dev, DMA_BIT_MASK(dma_width));
if (err) {
dev_err(>dev, "pci_set_dma_mask failed %d\n", err);
return err;
}
- err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(dma_width));
+ err = dma_set_coherent_mask(>dev, DMA_BIT_MASK(dma_width));
if (err) {
dev_err(>dev,
"err_pci_set_consistent_dma_mask failed %d\n",
--
2.17.1
[PATCH] iio: documentation: light: Add as73211 sysfs documentation
The driver for the as73211 light sensor provides the following not yet documented sysfs entries: - in_intensity_(x|y|z)_raw - in_intensity_(x|y|z)_scale - in_intensity_sampling_frequency(_available) - in_intensity_hardwaregain(_available) - in_intensity_integration_time Signed-off-by: Christian Eggers --- On Thursday, 6 August 2020, 19:44:51 CEST, Jonathan Cameron wrote: Hi Jonathan, > Hi Christian, > > I'll take this, but please send a follow up patch to add documentation > for in_intensity_x_raw and all the other new ABI this adds in > Documentation/ABI/testing/sysfs-bus-iio > I should have mentioned that earlier, but kind of assumed we already > had these documented for some reason! > [...] > Insert them into the relevant groups that already exist. In some cases > it will just be adding an entry with no specific explanation. > For the _raw attribute add a bit more info about what x, y and z are > (basically just say they are from cie1931 (I think?) I added all sysfs entries which were not present in 5.8-rc6. Best regards Christian Documentation/ABI/testing/sysfs-bus-iio | 26 - 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index d3e53a6d8331..14ae4bf053c5 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -40,6 +40,7 @@ Description: buffered samples and events for device X. What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency What: /sys/bus/iio/devices/iio:deviceX/buffer/sampling_frequency What: /sys/bus/iio/devices/triggerX/sampling_frequency KernelVersion: 2.6.35 @@ -55,6 +56,7 @@ Description: then it is to be found in the base device directory. What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency_available What: /sys/bus/iio/devices/iio:deviceX/in_proximity_sampling_frequency_available What: /sys/.../iio:deviceX/buffer/sampling_frequency_available What: /sys/bus/iio/devices/triggerX/sampling_frequency_available @@ -374,6 +376,9 @@ What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale What: /sys/bus/iio/devices/iio:deviceX/in_countY_scale What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_z_scale KernelVersion: 2.6.35 Contact: linux-...@vger.kernel.org Description: @@ -484,6 +489,7 @@ Description: are listed in this attribute. What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_hardwaregain What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain @@ -494,6 +500,13 @@ Description: Hardware applied gain factor. If shared across all channels, _hardwaregain is used. +What: /sys/bus/iio/devices/iio:deviceX/in_intensity_hardwaregain_available +KernelVersion: 5.10 +Contact: linux-...@vger.kernel.org +Description: + Lists all available hardware applied gain factors. Shared across all + channels. + What: /sys/.../in_accel_filter_low_pass_3db_frequency What: /sys/.../in_magn_filter_low_pass_3db_frequency What: /sys/.../in_anglvel_filter_low_pass_3db_frequency @@ -1333,6 +1346,7 @@ Description: standardised CIE Erythemal Action Spectrum. UV index values range from 0 (low) to >=11 (extreme). +What: /sys/.../iio:deviceX/in_intensity_integration_time What: /sys/.../iio:deviceX/in_intensity_red_integration_time What: /sys/.../iio:deviceX/in_intensity_green_integration_time What: /sys/.../iio:deviceX/in_intensity_blue_integration_time @@ -1342,7 +1356,8 @@ KernelVersion:3.12 Contact: linux-...@vger.kernel.org Description: This attribute is used to get/set the integration time in - seconds. + seconds. If shared across all channels, _integration_time + is used. What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_integration_time KernelVersion: 4.0 @@ -1739,3 +1754,12 @@ KernelVersion: 5.5 Contact: linux-...@vger.kernel.org Description: One of
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15: sparse: sparse: incorrect type in initializer (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: 9555152beb1143c85c03f9b9de59863cbbe89f4b Merge tag
'amd-drm-next-5.9-2020-07-01' of git://people.freedesktop.org/~agd5f/linux into
drm-next
date: 5 weeks ago
config: powerpc64-randconfig-s032-20200808 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 9555152beb1143c85c03f9b9de59863cbbe89f4b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
>> sparse: sparse: incorrect type in initializer (different address spaces) @@
>>expected unsigned long long [noderef] __user *__gu_addr @@ got
>> unsigned long long [usertype] * @@
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
>> sparse: expected unsigned long long [noderef] __user *__gu_addr
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c:172:15:
sparse: got unsigned long long [usertype] *
vim +172 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_device_queue_manager.c
b42902f4af8fec Yong Zhao 2020-02-05 155
d69fd951e60ae4 Mukul Joshi 2020-06-24 156 int
read_sdma_queue_counter(uint64_t q_rptr, uint64_t *val)
32cb59f3136248 Mukul Joshi 2020-05-26 157 {
32cb59f3136248 Mukul Joshi 2020-05-26 158 int ret;
32cb59f3136248 Mukul Joshi 2020-05-26 159 uint64_t tmp = 0;
32cb59f3136248 Mukul Joshi 2020-05-26 160
d69fd951e60ae4 Mukul Joshi 2020-06-24 161 if (!val)
32cb59f3136248 Mukul Joshi 2020-05-26 162 return -EINVAL;
32cb59f3136248 Mukul Joshi 2020-05-26 163 /*
32cb59f3136248 Mukul Joshi 2020-05-26 164 * SDMA activity counter is
stored at queue's RPTR + 0x8 location.
32cb59f3136248 Mukul Joshi 2020-05-26 165 */
d69fd951e60ae4 Mukul Joshi 2020-06-24 166 if (!access_ok((const void
__user *)(q_rptr +
32cb59f3136248 Mukul Joshi 2020-05-26 167
sizeof(uint64_t)), sizeof(uint64_t))) {
32cb59f3136248 Mukul Joshi 2020-05-26 168 pr_err("Can't access
sdma queue activity counter\n");
32cb59f3136248 Mukul Joshi 2020-05-26 169 return -EFAULT;
32cb59f3136248 Mukul Joshi 2020-05-26 170 }
32cb59f3136248 Mukul Joshi 2020-05-26 171
d69fd951e60ae4 Mukul Joshi 2020-06-24 @172 ret = get_user(tmp, (uint64_t
*)(q_rptr + sizeof(uint64_t)));
32cb59f3136248 Mukul Joshi 2020-05-26 173 if (!ret) {
32cb59f3136248 Mukul Joshi 2020-05-26 174 *val = tmp;
32cb59f3136248 Mukul Joshi 2020-05-26 175 }
32cb59f3136248 Mukul Joshi 2020-05-26 176
32cb59f3136248 Mukul Joshi 2020-05-26 177 return ret;
32cb59f3136248 Mukul Joshi 2020-05-26 178 }
32cb59f3136248 Mukul Joshi 2020-05-26 179
:: The code at line 172 was first introduced by commit
:: d69fd951e60ae48c8dd100aa8ceb799ab965f9b3 drm/amdkfd: Fix circular
locking dependency warning
:: TO: Mukul Joshi
:: CC: Alex Deucher
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v3 1/2] x86/cpufeatures: Enumerate TSX suspend load address tracking instructions
From: Kyung Min Park Intel TSX suspend load tracking instructions aim to give a way to choose which memory accesses do not need to be tracked in the TSX read set. Add TSX suspend load tracking CPUID feature flag TSXLDTRK for enumeration. A processor supports Intel TSX suspend load address tracking if CPUID.0x07.0x0:EDX[16] is present. Two instructions XSUSLDTRK, XRESLDTRK are available when this feature is present. The CPU feature flag is shown as "tsxldtrk" in /proc/cpuinfo. This instruction is currently documented in the the latest "extensions" manual (ISE). It will appear in the "main" manual (SDM) in the future. Signed-off-by: Kyung Min Park Signed-off-by: Cathy Zhang Reviewed-by: Tony Luck --- Changes since v2: * Shorten documentation names for readability. Links to documentation can be found in the cover letter. (Dave Hansen) --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 2901d5d..83fc9d3 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -368,6 +368,7 @@ #define X86_FEATURE_MD_CLEAR (18*32+10) /* VERW clears CPU buffers */ #define X86_FEATURE_TSX_FORCE_ABORT(18*32+13) /* "" TSX_FORCE_ABORT */ #define X86_FEATURE_SERIALIZE (18*32+14) /* SERIALIZE instruction */ +#define X86_FEATURE_TSXLDTRK (18*32+16) /* TSX Suspend Load Address Tracking */ #define X86_FEATURE_PCONFIG(18*32+18) /* Intel PCONFIG */ #define X86_FEATURE_ARCH_LBR (18*32+19) /* Intel ARCH LBR */ #define X86_FEATURE_SPEC_CTRL (18*32+26) /* "" Speculation Control (IBRS + IBPB) */ -- 1.8.3.1
[PATCH v3 0/2] Expose new features for Intel processor
This patchset is to expose two new features, SERIALIZE and TSX suspend load tracking to KVM CPUID for processors which support them. KVM reports this information and guest can make use of them finally. Detailed information on the instructions and CPUID feature flags can be found in the latest "extensions" manual [1]. This series applies on top of TIP tree as it depends on https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=85b23fbc7d88f8c6e3951721802d7845bc39663d Changes since v2: * Combine the two kvm patches into a single one. * Provide features' overview introduction in kvm patch commit message. * Get the latest kernel patches. * Change definition from TSX_LDTRK to TSXLDTRK for TSX new feature. * Change kernel patches Author to the owner. * Remove SERIALIZE enumeration patch. Reference: [1]. https://software.intel.com/content/dam/develop/public/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf Cathy Zhang (1): x86/kvm: Expose new features for supported cpuid Kyung Min Park (1): x86/cpufeatures: Enumerate TSX suspend load address tracking instructions arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kvm/cpuid.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH v3 2/2] x86/kvm: Expose new features for supported cpuid
Expose the SERIALIZE and TSX Suspend Load Address Tracking features in KVM CPUID, so when running on processors which support them, KVM could pass this information to guests and they can make use of these features accordingly. SERIALIZE is a faster serializing instruction which does not modify registers, arithmetic flags or memory, will not cause VM exit. It's availability is indicated by CPUID.(EAX=7,ECX=0):ECX[bit 14]. TSX suspend load tracking instruction aims to give a way to choose which memory accesses do not need to be tracked in the TSX read set. It's availability is indicated as CPUID.(EAX=7,ECX=0):EDX[bit 16]. Those instructions are currently documented in the the latest "extensions" manual (ISE). It will appear in the "main" manual (SDM) in the future. Signed-off-by: Cathy Zhang Reviewed-by: Tony Luck --- Changes since v2: * Merge two patches into a single one. (Luck, Tony) * Add overview introduction for features. (Sean Christopherson) * Refactor commit message to explain why expose feature bits. (Luck, Tony) --- arch/x86/kvm/cpuid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 8a294f9..dcf48cc 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -341,7 +341,8 @@ void kvm_set_cpu_caps(void) kvm_cpu_cap_mask(CPUID_7_EDX, F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) | F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) | - F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) + F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) | + F(SERIALIZE) | F(TSXLDTRK) ); /* TSC_ADJUST and ARCH_CAPABILITIES are emulated in software. */ -- 1.8.3.1
fs/zonefs/super.c:1110:6: warning: Variable 'ret' is reassigned a value before the old one has been used.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
commit: 8dcc1a9d90c10fa4143e5c17821082e5e60e46a1 fs: New zonefs file system
date: 6 months ago
compiler: alpha-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
cppcheck warnings: (new ones prefixed by >>)
>> fs/zonefs/super.c:1110:6: warning: Variable 'ret' is reassigned a value
>> before the old one has been used. [redundantAssignment]
ret = 0;
^
fs/zonefs/super.c:1045:0: note: Variable 'ret' is reassigned a value before
the old one has been used.
int ret = -ENOMEM;
^
fs/zonefs/super.c:1110:6: note: Variable 'ret' is reassigned a value before
the old one has been used.
ret = 0;
^
fs/zonefs/super.c:1257:6: warning: Variable 'ret' is reassigned a value
before the old one has been used. [redundantAssignment]
ret = 0;
^
fs/zonefs/super.c:1210:6: note: Variable 'ret' is reassigned a value before
the old one has been used.
ret = -EINVAL;
^
fs/zonefs/super.c:1257:6: note: Variable 'ret' is reassigned a value before
the old one has been used.
ret = 0;
^
vim +/ret +1110 fs/zonefs/super.c
1031
1032 /*
1033 * Create a zone group and populate it with zone files.
1034 */
1035 static int zonefs_create_zgroup(struct zonefs_zone_data *zd,
1036 enum zonefs_ztype type)
1037 {
1038 struct super_block *sb = zd->sb;
1039 struct zonefs_sb_info *sbi = ZONEFS_SB(sb);
1040 struct blk_zone *zone, *next, *end;
1041 const char *zgroup_name;
1042 char *file_name;
1043 struct dentry *dir;
1044 unsigned int n = 0;
1045 int ret = -ENOMEM;
1046
1047 /* If the group is empty, there is nothing to do */
1048 if (!zd->nr_zones[type])
1049 return 0;
1050
1051 file_name = kmalloc(ZONEFS_NAME_MAX, GFP_KERNEL);
1052 if (!file_name)
1053 return -ENOMEM;
1054
1055 if (type == ZONEFS_ZTYPE_CNV)
1056 zgroup_name = "cnv";
1057 else
1058 zgroup_name = "seq";
1059
1060 dir = zonefs_create_inode(sb->s_root, zgroup_name, NULL, type);
1061 if (!dir)
1062 goto free;
1063
1064 /*
1065 * The first zone contains the super block: skip it.
1066 */
1067 end = zd->zones + blkdev_nr_zones(sb->s_bdev->bd_disk);
1068 for (zone = >zones[1]; zone < end; zone = next) {
1069
1070 next = zone + 1;
1071 if (zonefs_zone_type(zone) != type)
1072 continue;
1073
1074 /*
1075 * For conventional zones, contiguous zones can be
aggregated
1076 * together to form larger files. Note that this
overwrites the
1077 * length of the first zone of the set of contiguous
zones
1078 * aggregated together. If one offline or read-only
zone is
1079 * found, assume that all zones aggregated have the same
1080 * condition.
1081 */
1082 if (type == ZONEFS_ZTYPE_CNV &&
1083 (sbi->s_features & ZONEFS_F_AGGRCNV)) {
1084 for (; next < end; next++) {
1085 if (zonefs_zone_type(next) != type)
1086 break;
1087 zone->len += next->len;
1088 if (next->cond ==
BLK_ZONE_COND_READONLY &&
1089 zone->cond != BLK_ZONE_COND_OFFLINE)
1090 zone->cond =
BLK_ZONE_COND_READONLY;
1091 else if (next->cond ==
BLK_ZONE_COND_OFFLINE)
1092 zone->cond =
BLK_ZONE_COND_OFFLINE;
1093 }
1094 }
1095
1096 /*
1097 * Use the file number within its group as file name.
1098 */
1099 snprintf(file_name, ZONEFS_NAME_MAX - 1, "%u", n);
1100 if (!zonefs_create_inode(dir, file_name, zone, type))
1101 goto free;
1102
1103 n++;
1104 }
1105
1106 zonefs_info(sb, "Zone group \"%s\" has %u file%s\n",
1107 zgroup_name, n, n > 1 ? "s" : "");
1108
1109 sbi->s_nr_files[type] = n;
> 1110 ret = 0;
1112 free:
1113 kfree(file_name);
1114
1115 return ret;
1116
Re: [PATCH 5/4] RDMA/efa : Remove pci-dma-compat wrapper APIs
On Sun, 2020-08-09 at 13:15 +0530, Suraj Upadhyay wrote:
> The legacy API wrappers in include/linux/pci-dma-compat.h
> should go away as it creates unnecessary midlayering
> for include/linux/dma-mapping.h APIs.
>
> Instead use dma-mapping.h APIs directly.
>
> The patch has been generated with the coccinelle script below
> and compile-tested.
[]
> diff --git a/drivers/infiniband/hw/efa/efa_main.c
> b/drivers/infiniband/hw/efa/efa_main.c
[]
> @@ -405,13 +405,13 @@ static int efa_device_init(struct efa_com_dev *edev,
> struct pci_dev *pdev)
> return err;
> }
>
> - err = pci_set_dma_mask(pdev, DMA_BIT_MASK(dma_width));
> + err = dma_set_mask(>dev, DMA_BIT_MASK(dma_width));
> if (err) {
> dev_err(>dev, "pci_set_dma_mask failed %d\n", err);
Coccinelle is great for some things, but not
necessarily for these sorts of changes in an
completely automated way.
The dev_err messages also need to be changed
as the format string contains the old name.
> - err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(dma_width));
> + err = dma_set_coherent_mask(>dev, DMA_BIT_MASK(dma_width));
> if (err) {
> dev_err(>dev,
> "err_pci_set_consistent_dma_mask failed %d\n",
Re: linux-next: build failure after merge of the thunderbolt tree
Hi Linus,
On Tue, 30 Jun 2020 16:03:46 +1000 Stephen Rothwell
wrote:
>
> After merging the thunderbolt tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
>
> Caused by commit
>
> 54509f5005ca ("thunderbolt: Add KUnit tests for path walking")
>
> interacting with commit
>
> d4cdd146d0db ("kunit: generalize kunit_resource API beyond allocated
> resources")
>
> from the kunit-next tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell
> Date: Tue, 30 Jun 2020 15:51:50 +1000
> Subject: [PATCH] thunderbolt: merge fix for kunix_resource changes
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/thunderbolt/test.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thunderbolt/test.c b/drivers/thunderbolt/test.c
> index acb8b6256847..a4d78811f7e2 100644
> --- a/drivers/thunderbolt/test.c
> +++ b/drivers/thunderbolt/test.c
> @@ -17,13 +17,13 @@ static int __ida_init(struct kunit_resource *res, void
> *context)
> struct ida *ida = context;
>
> ida_init(ida);
> - res->allocation = ida;
> + res->data = ida;
> return 0;
> }
>
> static void __ida_destroy(struct kunit_resource *res)
> {
> - struct ida *ida = res->allocation;
> + struct ida *ida = res->data;
>
> ida_destroy(ida);
> }
> --
> 2.27.0
>
> --
> Cheers,
> Stephen Rothwell
I looks like the above report got lost along the way to you :-(
Here's the patch in case you want to directly apply it:
From: Stephen Rothwell
Date: Tue, 30 Jun 2020 15:51:50 +1000
Subject: [PATCH] thunderbolt: merge fix for kunix_resource changes
Signed-off-by: Stephen Rothwell
---
drivers/thunderbolt/test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thunderbolt/test.c b/drivers/thunderbolt/test.c
index acb8b6256847..a4d78811f7e2 100644
--- a/drivers/thunderbolt/test.c
+++ b/drivers/thunderbolt/test.c
@@ -17,13 +17,13 @@ static int __ida_init(struct kunit_resource *res, void
*context)
struct ida *ida = context;
ida_init(ida);
- res->allocation = ida;
+ res->data = ida;
return 0;
}
static void __ida_destroy(struct kunit_resource *res)
{
- struct ida *ida = res->allocation;
+ struct ida *ida = res->data;
ida_destroy(ida);
}
--
Cheers,
Stephen Rothwell
pgp9V276M4lt5.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/4] Infiniband Subsystem: Remove pci-dma-compat wrapper APIs.
On 09/08/2020 10:24, Suraj Upadhyay wrote: > Hii Developers, > > This patch series will replace all the legacy pci-dma-compat wrappers > with the dma-mapping APIs directly in the INFINIBAND Subsystem. > > This task is done through a coccinelle script which is described in each > commit > message. > > The changes are compile tested. > > Thanks, > > Suraj Upadhyay. > > Suraj Upadhyay (4): > IB/hfi1: Remove pci-dma-compat wrapper APIs > IB/mthca: Remove pci-dma-compat wrapper APIs > RDMA/qib: Remove pci-dma-compat wrapper APIs > RDMA/pvrdma: Remove pci-dma-compat wrapper APIs > > drivers/infiniband/hw/hfi1/pcie.c | 8 +++ > drivers/infiniband/hw/hfi1/user_exp_rcv.c | 13 +-- > drivers/infiniband/hw/mthca/mthca_eq.c| 21 + > drivers/infiniband/hw/mthca/mthca_main.c | 8 +++ > drivers/infiniband/hw/mthca/mthca_memfree.c | 23 +++ > drivers/infiniband/hw/qib/qib_file_ops.c | 12 +- > drivers/infiniband/hw/qib/qib_init.c | 4 ++-- > drivers/infiniband/hw/qib/qib_pcie.c | 8 +++ > drivers/infiniband/hw/qib/qib_user_pages.c| 12 +- > .../infiniband/hw/vmw_pvrdma/pvrdma_main.c| 6 ++--- > 10 files changed, 59 insertions(+), 56 deletions(-) > The efa patch isn't listed here, and it shows as patch 5/4?
Re: [PATCH v2 5/6] openrisc: signal: Fix sparse address space warnings
On Sun, Aug 09, 2020 at 01:08:42AM +0200, Luc Van Oostenryck wrote: > On Sun, Aug 09, 2020 at 07:48:22AM +0900, Stafford Horne wrote: > > On Thu, Aug 06, 2020 at 09:04:49PM +0200, Luc Van Oostenryck wrote: > > > On Thu, Aug 06, 2020 at 06:07:24AM +0900, Stafford Horne wrote: > > > > --- > > > > arch/openrisc/kernel/signal.c | 14 +++--- > > > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/arch/openrisc/kernel/signal.c > > > > b/arch/openrisc/kernel/signal.c > > > > index 4f0754874d78..7ce0728412f6 100644 > > > > --- a/arch/openrisc/kernel/signal.c > > > > +++ b/arch/openrisc/kernel/signal.c > > > > @@ -76,7 +76,7 @@ asmlinkage long _sys_rt_sigreturn(struct pt_regs > > > > *regs) > > > > * then frame should be dword aligned here. If it's > > > > * not, then the user is trying to mess with us. > > > > */ > > > > - if (((long)frame) & 3) > > > > + if (((__force unsigned long)frame) & 3) > > > > goto badframe; > > > > > > Same as patch 6, the __force is not needed. > > > > Thanks, I thought this was complaining before, I tested now and there is no > > problem so I must have been mixed up with something else. > > Sparse should have complained with with the cast to long but > purposely doesn't with unsigned long (or uintptr_t). > So, no mix up, I think. You are right, I noticed that right after I sent that email. Thanks a lot. -Stafford
Re: [PATCH 0/4] Infiniband Subsystem: Remove pci-dma-compat wrapper APIs.
On Sun, Aug 09, 2020 at 11:35:51AM +0300, Gal Pressman wrote:
> On 09/08/2020 10:24, Suraj Upadhyay wrote:
> > Hii Developers,
> >
> > This patch series will replace all the legacy pci-dma-compat wrappers
> > with the dma-mapping APIs directly in the INFINIBAND Subsystem.
> >
> > This task is done through a coccinelle script which is described in each
> > commit
> > message.
> >
> > The changes are compile tested.
> >
> > Thanks,
> >
> > Suraj Upadhyay.
> >
> > Suraj Upadhyay (4):
> > IB/hfi1: Remove pci-dma-compat wrapper APIs
> > IB/mthca: Remove pci-dma-compat wrapper APIs
> > RDMA/qib: Remove pci-dma-compat wrapper APIs
> > RDMA/pvrdma: Remove pci-dma-compat wrapper APIs
> >
> > drivers/infiniband/hw/hfi1/pcie.c | 8 +++
> > drivers/infiniband/hw/hfi1/user_exp_rcv.c | 13 +--
> > drivers/infiniband/hw/mthca/mthca_eq.c| 21 +
> > drivers/infiniband/hw/mthca/mthca_main.c | 8 +++
> > drivers/infiniband/hw/mthca/mthca_memfree.c | 23 +++
> > drivers/infiniband/hw/qib/qib_file_ops.c | 12 +-
> > drivers/infiniband/hw/qib/qib_init.c | 4 ++--
> > drivers/infiniband/hw/qib/qib_pcie.c | 8 +++
> > drivers/infiniband/hw/qib/qib_user_pages.c| 12 +-
> > .../infiniband/hw/vmw_pvrdma/pvrdma_main.c| 6 ++---
> > 10 files changed, 59 insertions(+), 56 deletions(-)
> >
>
> The efa patch isn't listed here, and it shows as patch 5/4?
Yes, I forgot to add it in the queue.
Thought it would be nice if the patch ("efa") would be in the chain.
Though I am sending a v2 for that patch following joe perches suggestion.
Hope this wasn't an annoyance.
Thanks,
Suraj Upadhyay.
Re: [PATCH] arch/arm: use simple i2c probe function
On Fri, Aug 07, 2020 at 05:31:00PM +0200, Stephen Kitt wrote:
> The i2c probe functions here don't use the id information provided in
> their second argument, so the single-parameter i2c probe function
> ("probe_new") can be used instead.
>
> This avoids scanning the identifier tables during probes.
>
> Signed-off-by: Stephen Kitt
> ---
> arch/arm/mach-davinci/board-dm644x-evm.c | 5 ++---
> arch/arm/mach-davinci/board-dm646x-evm.c | 10 --
> arch/arm/mach-s3c64xx/mach-crag6410-module.c | 5 ++---
> 3 files changed, 8 insertions(+), 12 deletions(-)
>
Hi,
You need to split it per sub architecture maintainers. The subject
prefix is then for example: "ARM: s3c64xx: ".
Best regards,
Krzysztof
Re: linux-next: manual merge of the f2fs tree with the fscrypt tree
Hi all,
On Wed, 8 Jul 2020 10:38:58 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the f2fs tree got a conflict in:
>
> Documentation/filesystems/f2fs.rst
>
> between commit:
>
> 38dff4e50c12 ("f2fs: add inline encryption support")
>
> from the fscrypt tree and commit:
>
> a7c77c387b60 ("f2fs: fix to document reserved special compression
> extension")
>
> from the f2fs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc Documentation/filesystems/f2fs.rst
> index 8b4fac44f4e1,535021c46260..
> --- a/Documentation/filesystems/f2fs.rst
> +++ b/Documentation/filesystems/f2fs.rst
> @@@ -258,13 -258,8 +258,15 @@@ compress_extension=%s Support adding s
> on compression extension list and enable compression
> on
> these file by default rather than to enable it via
> ioctl.
> For other files, we can still enable compression via
> ioctl.
> +Note that, there is one reserved special extension
> '*', it
> +can be set to enable compression for all files.
> +inlinecrypt
> + When possible, encrypt/decrypt the contents of
> encrypted
> + files using the blk-crypto framework rather than
> + filesystem-layer encryption. This allows the use of
> + inline encryption hardware. The on-disk format is
> + unaffected. For more details, see
> + Documentation/block/inline-encryption.rst.
> ==
>
>
> Debugfs Entries
This is now a conflict between the f2fs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpQO7ZjDYKqP.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 09/41] usb: gadget: s3c-hsudc: remove platform header dependency
On Fri, Aug 07, 2020 at 07:42:30PM +0200, Arnd Bergmann wrote: > On Fri, Aug 7, 2020 at 3:59 PM Felipe Balbi wrote: > > Krzysztof Kozlowski writes: > > > > +#include > > > + > > > #define S3C2443_CLKREG(x)((x) + S3C24XX_VA_CLKPWR) > > > > > > #define S3C2443_PLLCON_MDIVSHIFT 16 > > > @@ -184,5 +186,52 @@ s3c2443_get_epll(unsigned int pllval, unsigned int > > > baseclk) > > > return (unsigned int)fvco; > > > } > > > > > > +static inline void s3c_hsudc_init_phy(void) > > > > This should, really, be a PHY driver under drivers/phy, since the goal > > is to make this platform-independent, might as well take the opportunity > > to introduce a proper driver, no? > > In theory, this is absolutely correct. I fear it will be hard to find anyone > to make a larger scale cleanup of the file however. As my old changelog > text says, there is only one board (smdk2416) in the kernel that registers > the device. My change was the minimum to keep it working during the > move to a multiplatform configuration, but if there is someone who has > the hardware and volunteers to make a proper phy driver, that would also > work. > > As the board only exists as a reference for other boards, but none of those > made it into the kernel, we could alternatively just decide to drop the > driver. There is also a .dts file for the board, which is lacking a device > node > for the udc (and the driver lacks DT support), so that board file could also > be dropped then, leaving only the DT version as a reference for the SoC. All this is a work on a very old SoC with an unknown number of current/real users. I don't have the hardware to test so I would prefer to skip any big changes. As Arnd suggests, we could just drop this one board and the driver... or if it does not harm/bother to much we could keep it as is, just without platform header dependency. Someone still might be using it. Best regards, Krzysztof
Re: [PATCH net] drivers/net/wan/lapbether: Added needed_tailroom
On Sat, Aug 8, 2020 at 7:53 PM Xie He wrote: > > The underlying Ethernet device may request necessary tailroom to be > allocated by setting needed_tailroom. This driver should also set > needed_tailroom to request the tailroom needed by the underlying > Ethernet device to be allocated. > > Cc: Willem de Bruijn > Cc: Martin Schiller > Signed-off-by: Xie He > --- > drivers/net/wan/lapbether.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c > index 1ea15f2123ed..cc297ea9c6ec 100644 > --- a/drivers/net/wan/lapbether.c > +++ b/drivers/net/wan/lapbether.c > @@ -340,6 +340,7 @@ static int lapbeth_new_device(struct net_device *dev) > */ > ndev->needed_headroom = -1 + 3 + 2 + dev->hard_header_len >+ dev->needed_headroom; > + ndev->needed_tailroom = dev->needed_tailroom; Does this solve an actual observed bug? In many ways lapbeth is similar to tunnel devices. This is not common.
Re: linux-next: manual merge of the spi tree with the mtd tree
Hi all,
On Wed, 8 Jul 2020 14:37:59 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the spi tree got conflicts in:
>
> drivers/memory/Kconfig
> drivers/memory/Makefile
>
> between commit:
>
> 66b8173a197f ("memory: stm32-fmc2-ebi: add STM32 FMC2 EBI controller
> driver")
>
> from the mtd tree and commit:
>
> ca7d8b980b67 ("memory: add Renesas RPC-IF driver")
>
> from the spi tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
>
> diff --cc drivers/memory/Kconfig
> index be69c07b8941,e438d79857da..
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@@ -174,16 -174,15 +174,25 @@@ config PL353_SM
> This driver is for the ARM PL351/PL353 Static Memory
> Controller(SMC) module.
>
> + config RENESAS_RPCIF
> + tristate "Renesas RPC-IF driver"
> + depends on ARCH_RENESAS
> + select REGMAP_MMIO
> + help
> + This supports Renesas R-Car Gen3 RPC-IF which provides either SPI
> + host or HyperFlash. You'll have to select individual components
> + under the corresponding menu.
> +
> +config STM32_FMC2_EBI
> +tristate "Support for FMC2 External Bus Interface on STM32MP SoCs"
> +depends on MACH_STM32MP157 || COMPILE_TEST
> +select MFD_SYSCON
> +help
> + Select this option to enable the STM32 FMC2 External Bus Interface
> + controller. This driver configures the transactions with external
> + devices (like SRAM, ethernet adapters, FPGAs, LCD displays, ...) on
> + SOCs containing the FMC2 External Bus Interface.
> +
> source "drivers/memory/samsung/Kconfig"
> source "drivers/memory/tegra/Kconfig"
>
> diff --cc drivers/memory/Makefile
> index d3d8d6ced342,d105f8ebe8b8..
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@@ -22,7 -22,7 +22,8 @@@ obj-$(CONFIG_JZ4780_NEMC) += jz4780-nem
> obj-$(CONFIG_MTK_SMI) += mtk-smi.o
> obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o
> obj-$(CONFIG_PL353_SMC) += pl353-smc.o
> + obj-$(CONFIG_RENESAS_RPCIF) += renesas-rpc-if.o
> +obj-$(CONFIG_STM32_FMC2_EBI)+= stm32-fmc2-ebi.o
>
> obj-$(CONFIG_SAMSUNG_MC)+= samsung/
> obj-$(CONFIG_TEGRA_MC) += tegra/
This is now a conflict between the mtd tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpSnOn9JmaEB.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
On Mon, 13 Jul 2020 14:39:35 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm-arm tree got conflicts in:
>
> arch/arm64/include/asm/kvm_coproc.h
> arch/arm64/kvm/handle_exit.c
>
> between commit:
>
> 74cc7e0c35c1 ("KVM: arm64: clean up redundant 'kvm_run' parameters")
>
> from the kvm tree and commits:
>
> 6b33e0d64f85 ("KVM: arm64: Drop the target_table[] indirection")
> 750ed5669380 ("KVM: arm64: Remove the target table")
> 3a949f4c9354 ("KVM: arm64: Rename HSR to ESR")
>
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/arm64/include/asm/kvm_coproc.h
> index 454373704b8a,147f3a77e6a5..
> --- a/arch/arm64/include/asm/kvm_coproc.h
> +++ b/arch/arm64/include/asm/kvm_coproc.h
> @@@ -19,20 -19,12 +19,12 @@@ struct kvm_sys_reg_table
> size_t num;
> };
>
> - struct kvm_sys_reg_target_table {
> - struct kvm_sys_reg_table table64;
> - struct kvm_sys_reg_table table32;
> - };
> -
> - void kvm_register_target_sys_reg_table(unsigned int target,
> -struct kvm_sys_reg_target_table *table);
> -
> -int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
> -int kvm_handle_sys_reg(struct kvm_vcpu *vcpu, struct kvm_run *run);
> +int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp14_32(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp14_64(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp15_32(struct kvm_vcpu *vcpu);
> +int kvm_handle_cp15_64(struct kvm_vcpu *vcpu);
> +int kvm_handle_sys_reg(struct kvm_vcpu *vcpu);
>
> #define kvm_coproc_table_init kvm_sys_reg_table_init
> void kvm_sys_reg_table_init(void);
> diff --cc arch/arm64/kvm/handle_exit.c
> index 1df3beafd73f,98ab33139982..
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@@ -87,9 -87,9 +87,9 @@@ static int handle_no_fpsimd(struct kvm_
>* world-switches and schedule other host processes until there is an
>* incoming IRQ or FIQ to the VM.
>*/
> -static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +static int kvm_handle_wfx(struct kvm_vcpu *vcpu)
> {
> - if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> + if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
> vcpu->stat.wfe_exit_stat++;
> kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> @@@ -114,12 -115,11 +114,12 @@@
>* guest and host are using the same debug facilities it will be up to
>* userspace to re-inject the correct exception for guest delivery.
>*
> - * @return: 0 (while setting run->exit_reason), -1 for error
> + * @return: 0 (while setting vcpu->run->exit_reason), -1 for error
>*/
> -static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run
> *run)
> +static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
> {
> +struct kvm_run *run = vcpu->run;
> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
> + u32 esr = kvm_vcpu_get_esr(vcpu);
> int ret = 0;
>
> run->exit_reason = KVM_EXIT_DEBUG;
> @@@ -144,12 -144,12 +144,12 @@@
> return ret;
> }
>
> -static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
> {
> - u32 hsr = kvm_vcpu_get_hsr(vcpu);
> + u32 esr = kvm_vcpu_get_esr(vcpu);
>
> - kvm_pr_unimpl("Unknown exception class: hsr: %#08x -- %s\n",
> - hsr, esr_get_class_string(hsr));
> + kvm_pr_unimpl("Unknown exception class: esr: %#08x -- %s\n",
> + esr, esr_get_class_string(esr));
>
> kvm_inject_undefined(vcpu);
> return 1;
> @@@ -237,12 -237,11 +237,12 @@@ static int handle_trap_exceptions(struc
>* Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>* proper exit to userspace.
>*/
> -int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
> - int exception_index)
> +int handle_exit(struct kvm_vcpu *vcpu, int exception_index)
> {
> +struct kvm_run *run = vcpu->run;
> +
> if (ARM_SERROR_PENDING(exception_index)) {
> - u8 hsr_ec = ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
> + u8 esr_ec =
Re: linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
On Mon, 13 Jul 2020 14:40:36 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
>
> arch/arm64/kvm/mmu.c
>
> between commit:
>
> c1a33aebe91d ("KVM: arm64: Use common KVM implementation of MMU memory
> caches")
>
> from the kvm tree and commit:
>
> a0e50aa3f4a8 ("KVM: arm64: Factor out stage 2 page table data from struct
> kvm")
>
> from the kvm-arm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/arm64/kvm/mmu.c
> index 838aad520f1c,cd14c831d56f..
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@@ -124,11 -127,44 +127,12 @@@ static void stage2_dissolve_pud(struct
> put_page(virt_to_page(pudp));
> }
>
> - static void clear_stage2_pgd_entry(struct kvm *kvm, pgd_t *pgd, phys_addr_t
> addr)
> -static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
> - int min, int max)
> -{
> -void *page;
> -
> -BUG_ON(max > KVM_NR_MEM_OBJS);
> -if (cache->nobjs >= min)
> -return 0;
> -while (cache->nobjs < max) {
> -page = (void *)__get_free_page(GFP_PGTABLE_USER);
> -if (!page)
> -return -ENOMEM;
> -cache->objects[cache->nobjs++] = page;
> -}
> -return 0;
> -}
> -
> -static void mmu_free_memory_cache(struct kvm_mmu_memory_cache *mc)
> -{
> -while (mc->nobjs)
> -free_page((unsigned long)mc->objects[--mc->nobjs]);
> -}
> -
> -static void *mmu_memory_cache_alloc(struct kvm_mmu_memory_cache *mc)
> -{
> -void *p;
> -
> -BUG_ON(!mc || !mc->nobjs);
> -p = mc->objects[--mc->nobjs];
> -return p;
> -}
> -
> + static void clear_stage2_pgd_entry(struct kvm_s2_mmu *mmu, pgd_t *pgd,
> phys_addr_t addr)
> {
> + struct kvm *kvm = mmu->kvm;
> p4d_t *p4d_table __maybe_unused = stage2_p4d_offset(kvm, pgd, 0UL);
> stage2_pgd_clear(kvm, pgd);
> - kvm_tlb_flush_vmid_ipa(kvm, addr);
> + kvm_tlb_flush_vmid_ipa(mmu, addr, S2_NO_LEVEL_HINT);
> stage2_p4d_free(kvm, p4d_table);
> put_page(virt_to_page(pgd));
> }
This is now a conflict between the kvm-arm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpOv5NIHwSwj.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the set_fs tree with the powerpc tree
Hi all,
On Fri, 17 Jul 2020 19:09:31 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the set_fs tree got a conflict in:
>
> arch/powerpc/mm/numa.c
>
> between commit:
>
> c30f931e891e ("powerpc/numa: remove ability to enable topology updates")
>
> from the powerpc tree and commit:
>
> 16a04bde8169 ("proc: switch over direct seq_read method calls to
> seq_read_iter")
>
> from the set_fs tree.
>
> I fixed it up (the former removed the code updated by the latter, so I
> just did that) and can carry the fix as necessary. This is now fixed as
> far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging. You may also want to consider cooperating with the maintainer
> of the conflicting tree to minimise any particularly complex conflicts.
This is now a conflict between the set_fs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpER2g8yV3g1.pgp
Description: OpenPGP digital signature
[PATCH] ASoC: intel: Fix memleak in sst_media_open
When power_up_sst() fails, stream needs to be freed
just like when try_module_get() fails. However, current
code is returning directly and ends up leaking memory.
Fixes: 0121327c1a68b ("ASoC: Intel: mfld-pcm: add control for powering up/down
dsp")
Signed-off-by: Dinghao Liu
---
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
index 49b9f18472bc..79fedf9e3da1 100644
--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
@@ -330,8 +330,10 @@ static int sst_media_open(struct snd_pcm_substream
*substream,
runtime->private_data = stream;
ret_val = power_up_sst(stream);
- if (ret_val < 0)
+ if (ret_val < 0) {
+ kfree(stream);
return ret_val;
+ }
/* Make sure, that the period size is always even */
snd_pcm_hw_constraint_step(substream->runtime, 0,
--
2.17.1
Re: linux-next: manual merge of the set_fs tree with the battery tree
Hi all,
On Mon, 27 Jul 2020 21:01:37 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the set_fs tree got a conflict in:
>
> drivers/power/supply/da9030_battery.c
>
> between commit:
>
> 9d832cd36c60 ("power: Convert to DEFINE_SHOW_ATTRIBUTE")
>
> from the battery tree and commit:
>
> 4d4901c6d748 ("seq_file: switch over direct seq_read method calls to
> seq_read_iter")
>
> from the set_fs tree.
>
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
This is nw a conflict between the set_fs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpKwxRRKOlpz.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the set_fs tree with the tip tree
Hi all,
On Mon, 27 Jul 2020 21:04:44 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the set_fs tree got a conflict in:
>
> lib/debugobjects.c
>
> between commit:
>
> 0f85c4805184 ("debugobjects: Convert to DEFINE_SHOW_ATTRIBUTE")
>
> from the tip tree and commit:
>
> 4d4901c6d748 ("seq_file: switch over direct seq_read method calls to
> seq_read_iter")
>
> from the set_fs tree.
>
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
This is now a conflict between the set_fs tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpqsWzDAq69r.pgp
Description: OpenPGP digital signature
Re: [RFC] memory: exynos5422-dmc: Document mutex scope
On Tue, Aug 04, 2020 at 11:40:07AM +0100, Lukasz Luba wrote:
> Hi Krzysztof,
>
> On 7/24/20 7:08 PM, Krzysztof Kozlowski wrote:
> > Document scope of the mutex used by driver.
> >
> > Signed-off-by: Krzysztof Kozlowski
> >
> > ---
> >
> > It seems mutex was introduced to protect:
> > 1. setting actual frequency/voltage,
> > 2. dmc->curr_rate (in exynos5_dmc_get_cur_freq()).
> >
> > However dmc->curr_rate in exynos5_dmc_get_status() is not protected. Is
> > it a bug?
>
> The callback get_dev_status() from devfreq->profile, which here is the
> exynos5_dmc_get_status() should be already called with devfreq->lock
> mutex hold, like e.g from simple_ondemand governor or directly
> using update_devfreq exported function:
> update_devfreq()
> ->get_target_freq()
> devfreq_update_stats()
> df->profile->get_dev_status()
>
> The dmc->curr_rate is also used from sysfs interface from devfreq.
> The local dmc lock serializes also this use case (when the HW freq
> has changed but not set yet into curr_rate.
These are different locks. You cannot protect dmc->curr_rate with
devfreq->lock in one place and dmc-lock in other place. This won't
protect it.
> > ---
> > drivers/memory/samsung/exynos5422-dmc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/memory/samsung/exynos5422-dmc.c
> > b/drivers/memory/samsung/exynos5422-dmc.c
> > index 93e9c2429c0d..0388066a7d96 100644
> > --- a/drivers/memory/samsung/exynos5422-dmc.c
> > +++ b/drivers/memory/samsung/exynos5422-dmc.c
> > @@ -114,6 +114,7 @@ struct exynos5_dmc {
> > void __iomem *base_drexi0;
> > void __iomem *base_drexi1;
> > struct regmap *clk_regmap;
> > + /* Protects curr_rate and frequency/voltage setting section */
> > struct mutex lock;
> > unsigned long curr_rate;
> > unsigned long curr_volt;
> >
>
> I assume this missing comment for the lock was required by some scripts.
> In this case LGTM:
>
> Reviewed-by: Lukasz Luba
Such comments are always useful. It is also pointed by strict
checkpatch:
CHECK: struct mutex definition without comment
Best regards,
Krzysztof
Re: [PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
On Sun, Aug 9, 2020 at 4:36 AM Xie He wrote:
>
> 1. Added a skb->len check
>
> This driver expects upper layers to include a pseudo header of 1 byte
> when passing down a skb for transmission. This driver will read this
> 1-byte header. This patch added a skb->len check before reading the
> header to make sure the header exists.
>
> 2. Added needed_headroom
>
> When this driver transmits data,
> first this driver will remove a pseudo header of 1 byte,
> then the lapb module will prepend the LAPB header of 2 or 3 bytes.
> So the value of needed_headroom in this driver should be 3 - 1.
>
> Cc: Willem de Bruijn
> Cc: Martin Schiller
> Signed-off-by: Xie He
The patch is analogous to commit c7ca03c216ac
("drivers/net/wan/lapbether: Added needed_headroom and a skb->len
check").
Seems to make sense based on call stack
x25_asy_xmit // skb_pull(skb, 1)
lapb_data_request
lapb_kick
lapb_send_iframe// skb_push(skb, 2)
lapb_transmit_buffer// skb_push(skb, 1)
lapb_data_transmit
x25_asy_data_transmit
x25_asy_encaps
But I frankly don't know this code and would not modify logic that no
one has complained about for many years without evidence of a real
bug.
Were you able to actually exercise this path, similar to lapb_ether:
configure the device, send data from a packet socket? If so, can you
share the configuration steps?
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 08.08.20 17:05, Alan Stern wrote:
> On Sat, Aug 08, 2020 at 08:59:09AM +0200, Martin Kepplinger wrote:
>> On 07.08.20 16:30, Alan Stern wrote:
>>> On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
it's really strange: below is the change I'm trying. Of course that's
only for testing the functionality, nothing how a patch could look like.
While I remember it had worked, now (weirdly since I tried that mounting
via fstab) it doesn't anymore!
What I understand (not much): I handle the error with "retry" via the
new flag, but scsi_decide_disposition() returns SUCCESS because of "no
more retries"; but it's the first and only time it's called.
>>>
>>> Are you saying that scmd->allowed is set to 0? Or is scsi_notry_cmd()
>>> returning a nonzero value? Whichever is true, why does it happen that
>>> way?
>>
>> scsi_notry_cmd() is returning 1. (it's retry 1 of 5 allowed).
>>
>> why is it returning 1? REQ_FAILFAST_DEV is set. It's DID_OK, then "if
>> (status_byte(scmd->result) != CHECK_CONDITION)" appearently is not true,
>> then at the end it returns 1 because of REQ_FAILFAST_DEV.
>>
>> that seems to come from the block layer. why and when? could I change
>> that so that the scsi error handling stays in control?
>
> The only place I see where that flag might get set is in
> blk_mq_bio_to_request() in block/blk-mq.c, which does:
>
> if (bio->bi_opf & REQ_RAHEAD)
> rq->cmd_flags |= REQ_FAILFAST_MASK;
>
> So apparently read-ahead reads are supposed to fail fast (i.e., without
> retries), presumably because they are optional after all.
>
>>> What is the failing command? Is it a READ(10)?
>>
>> Not sure how I'd answer that, but here's the test to trigger the error:
>>
>> mount /dev/sda1 /mnt
>> cd /mnt
>> ls
>> cp file ~/ (if ls "works" and doesn't yet trigger the error)
>>
>> and that's the (familiar looking) logs when doing so. again: despite the
>> mentioned workaround in scsi_error and the new expected_media_change
>> flag *is* set and gets cleared, as it should be. REQ_FAILFAST_DEV seems
>> to override what I want to do is scsi_error:
>>
>> [ 55.557629] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
>> hostbyte=0x00 driverbyte=0x08 cmd_age=0s
>> [ 55.557639] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
>> [ 55.557646] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0
>> [ 55.557657] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 08 fc
>> e0 00 00 01 00
>
> Yes, 0x28 is READ(10). Likely this is a read-ahead request, although I
> don't know how we can tell for sure.
>
>> [ 55.557666] blk_update_request: I/O error, dev sda, sector 589024 op
>> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
>> [ 55.568899] sd 0:0:0:0: [sda] tag#0 device offline or changed
>> [ 55.574691] blk_update_request: I/O error, dev sda, sector 589025 op
>> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
>> [ 55.585756] sd 0:0:0:0: [sda] tag#0 device offline or changed
>> [ 55.591562] blk_update_request: I/O error, dev sda, sector 589026 op
>> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
>> [ 55.602274] sd 0:0:0:0: [sda] tag#0 device offline or changed
>> (... goes on with the same)
>
> Is such a drastic response really appropriate for the failure of a
> read-ahead request? It seems like a more logical response would be to
> let the request fail but keep the device online.
>
> Of course, that would only solve part of your problem -- your log would
> still get filled with those "I/O error" messages even though they
> wouldn't be fatal. Probably a better approach would be to make the new
> expecting_media_change flag override scsi_no_retry_cmd().
>
> But this is not my area of expertise. Maybe someone else will have more
> to say.
>
> Alan Stern
>
Hey Alan, I'm really glad for that, I suspected some of this but I have
little experience in scsi/block layers, so that is super helpful.
I'd appreciate an opinion on the below workaround that *seems* to work
now (let's see, I had thought so before :)
Whether or not this helps to find a real solution, let's see. But
integration of such a flag in the error handling paths is what's
interesting for now:
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -565,6 +565,17 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
return NEEDS_RETRY;
}
}
+ if (scmd->device->expecting_media_change) {
+ if (sshdr.asc == 0x28 && sshdr.ascq == 0x00) {
+ /* clear expecting_media_change in
+* scsi_noretry_cmd() because we need
+* to override possible "failfast" overrides
+* that block readahead can cause.
+*/
+ return NEEDS_RETRY;
+ }
+ }
+
[PATCH] mwifiex: Do not use GFP_KERNEL in atomic context
A possible call chain is as follow:
mwifiex_sdio_interrupt(sdio.c)
--> mwifiex_main_process(main.c)
--> mwifiex_process_cmdresp (cmdevt.c)
--> mwifiex_process_sta_cmdresp (sta_cmdresp.c)
--> mwifiex_ret_802_11_scan (scan.c)
--> mwifiex_parse_single_response_buf (scan.c)
'mwifiex_sdio_interrupt()' is an interrupt function.
Also note that 'mwifiex_ret_802_11_scan()' already uses GFP_ATOMIC.
So use GFP_ATOMIC instead of GFP_KERNEL when memory is allocated in
'mwifiex_parse_single_response_buf()'.
Fixes: 7c6fa2a843c5 ("mwifiex: use cfg80211 dynamic scan table and
cfg80211_get_bss API")
or
Fixes: 601216e12c65e ("mwifiex: process RX packets in SDIO IRQ thread directly")
Signed-off-by: Christophe JAILLET
---
This is completely speculative. I don't know if the call chain given above
if possible in RL application.
So review carefully :)
I'm not sure of the Fixes tag. If I'm correct:
- The first one is when the GFP_KERNEL has been introduced.
- the 2nd one is when some logic has been changed to call interrupt
handler directly instead of existing workqueue
Note that if my analysis is completely broken, it is likely that
'mwifiex_ret_802_11_scan()' could use GFP_KERNEL in order to relax some
memory allocation constrains.
---
drivers/net/wireless/marvell/mwifiex/scan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
b/drivers/net/wireless/marvell/mwifiex/scan.c
index ff932627a46c..2fb69a590bd8 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1889,7 +1889,7 @@ mwifiex_parse_single_response_buf(struct mwifiex_private
*priv, u8 **bss_info,
chan, CFG80211_BSS_FTYPE_UNKNOWN,
bssid, timestamp,
cap_info_bitmap, beacon_period,
- ie_buf, ie_len, rssi, GFP_KERNEL);
+ ie_buf, ie_len, rssi, GFP_ATOMIC);
if (bss) {
bss_priv = (struct mwifiex_bss_priv *)bss->priv;
bss_priv->band = band;
--
2.25.1
Re: [TEGRA194_CPUFREQ PATCH v6 3/3] cpufreq: Add Tegra194 cpufreq driver
On Sat, Aug 08, 2020 at 05:40:09PM -0700, Guenter Roeck wrote: > On Wed, Jul 15, 2020 at 07:01:25PM +0530, Sumit Gupta wrote: > > Add support for CPU frequency scaling on Tegra194. The frequency > > of each core can be adjusted by writing a clock divisor value to > > a MSR on the core. The range of valid divisors is queried from > > the BPMP. > > > > Signed-off-by: Mikko Perttunen > > Signed-off-by: Sumit Gupta > > If built as module: > > ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] > undefined! The exporting of this arm64 symbol went in last night. -- Catalin
[PATCH v6 2/4] SFH: PCIe driver to add support of AMD sensor fusion
From: Sandeep Singh
AMD SFH uses HID over PCIe bus.SFH fw is part of MP2 processor
(MP2 which is an ARM® Cortex-M4 core based co-processor to x86) and
it runs on MP2 where in driver resides on X86. This part of module
will communicate with MP2 FW and provide that data into DRAM
Signed-off-by: Nehal Shah
Signed-off-by: Sandeep Singh
---
drivers/hid/Kconfig| 2 +
drivers/hid/Makefile | 2 +
drivers/hid/amd-sfh-hid/Kconfig| 21
drivers/hid/amd-sfh-hid/Makefile | 15 +++
drivers/hid/amd-sfh-hid/amd_mp2_pcie.c | 162 +
drivers/hid/amd-sfh-hid/amd_mp2_pcie.h | 83 +
6 files changed, 285 insertions(+)
create mode 100644 drivers/hid/amd-sfh-hid/Kconfig
create mode 100644 drivers/hid/amd-sfh-hid/Makefile
create mode 100644 drivers/hid/amd-sfh-hid/amd_mp2_pcie.c
create mode 100644 drivers/hid/amd-sfh-hid/amd_mp2_pcie.h
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 45e87dc59d4e..c0a1c07ed6b1 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1174,4 +1174,6 @@ source "drivers/hid/i2c-hid/Kconfig"
source "drivers/hid/intel-ish-hid/Kconfig"
+source "drivers/hid/amd-sfh-hid/Kconfig"
+
endmenu
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index d8ea4b8c95af..7d8ca4e34572 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -141,3 +141,5 @@ obj-$(CONFIG_I2C_HID) += i2c-hid/
obj-$(CONFIG_INTEL_ISH_HID)+= intel-ish-hid/
obj-$(INTEL_ISH_FIRMWARE_DOWNLOADER) += intel-ish-hid/
+
+obj-$(CONFIG_AMD_SFH_HID) += amd-sfh-hid/
diff --git a/drivers/hid/amd-sfh-hid/Kconfig b/drivers/hid/amd-sfh-hid/Kconfig
new file mode 100644
index ..e73cf9fe1324
--- /dev/null
+++ b/drivers/hid/amd-sfh-hid/Kconfig
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+menu "AMD SFH HID support"
+ depends on X86_64 || COMPILE_TEST
+ depends on PCI
+
+config AMD_SFH_HID
+ tristate "AMD Sensor Fusion Hub"
+ select HID
+ help
+ If you say yes to this option, support will be included for the AMD
+ Sensor Fusion Hub.
+ This driver will enable sensors functionality to user through HID
+ framework. Basically this driver will get data from MP2 FW
+ and provide that data to HID framework.
+ MP2 which is an ARM® Cortex-M4 core based co-processor to x86.
+
+ This driver can also be built as modules. If so, the modules will
+ be called amd-sfhtp-hid.
+ Say Y or M here if you want to support AMD SFH. If unsure, say N.
+
+endmenu
diff --git a/drivers/hid/amd-sfh-hid/Makefile b/drivers/hid/amd-sfh-hid/Makefile
new file mode 100644
index ..a163c7f62b32
--- /dev/null
+++ b/drivers/hid/amd-sfh-hid/Makefile
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Makefile - AMD SFH HID drivers
+# Copyright (c) 2019-2020, Advanced Micro Devices, Inc.
+#
+#
+
+ccflags-m := -Werror
+ obj-$(CONFIG_AMD_SFH_HID) +=amd-sfhtp-hid.o
+ amd-sfhtp-hid-objs := amdsfh_hid.o
+ amd-sfhtp-hid-objs+= amdsfh_hid_client.o
+ amd-sfhtp-hid-objs+= amd_mp2_pcie.o
+ amd-sfhtp-hid-objs+= hid_descriptor/amd_sfh_hid_descriptor.o
+
+ccflags-y += -I$(srctree)/$(src)/
diff --git a/drivers/hid/amd-sfh-hid/amd_mp2_pcie.c
b/drivers/hid/amd-sfh-hid/amd_mp2_pcie.c
new file mode 100644
index ..cdd480c287db
--- /dev/null
+++ b/drivers/hid/amd-sfh-hid/amd_mp2_pcie.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * AMD MP2 PCIe communication driver
+ * Copyright 2020 Advanced Micro Devices, Inc.
+ *
+ * Authors: Shyam Sundar S K
+ * Sandeep Singh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "amd_mp2_pcie.h"
+
+#define DRIVER_NAME"pcie_mp2_amd"
+#define DRIVER_DESC"AMD(R) PCIe MP2 Communication Driver"
+
+#define ACEL_ENBIT(accel_idx)
+#define GYRO_ENBIT(gyro_idx)
+#define MAGNO_EN BIT(mag_idx)
+#define ALS_EN BIT(als_idx)
+
+void amd_start_sensor(struct amd_mp2_dev *privdata, struct amd_mp2_sensor_info
info)
+{
+ union sfh_cmd_param cmd_param;
+ union sfh_cmd_base cmd_base;
+
+ /* fill up command register */
+ cmd_base.ul = 0;
+ cmd_base.s.cmd_id = enable_sensor;
+ cmd_base.s.period = info.period;
+ cmd_base.s.sensor_id = info.sensor_idx;
+
+ /* fill up command param register */
+ cmd_param.ul = 0;
+ cmd_param.s.buf_layout = 1;
+ cmd_param.s.buf_length = 16;
+
+ writeq(info.phys_address, privdata->mmio + AMD_C2P_MSG2);
+ writel(cmd_param.ul, privdata->mmio + AMD_C2P_MSG1);
+ writel(cmd_base.ul, privdata->mmio + AMD_C2P_MSG0);
+}
+
+void amd_stop_sensor(struct amd_mp2_dev *privdata, u16 sensor_idx)
+{
+ union sfh_cmd_base cmd_base;
+
+ /* fill up command register */
+ cmd_base.ul = 0;
+
[PATCH v6 4/4] SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH)
From: Sandeep Singh
This part of module will define the data into HID reports. Get data from
PCIe layer and populate that data into reports. HID core communication
between devices and HID core is mostly done via HID reports.
Signed-off-by: Nehal Shah
Signed-off-by: Sandeep Singh
---
.../hid_descriptor/amd_sfh_hid_descriptor.c | 226 ++
.../hid_descriptor/amd_sfh_hid_descriptor.h | 121
.../amd_sfh_hid_report_descriptor.h | 645 ++
3 files changed, 992 insertions(+)
create mode 100644
drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.c
create mode 100644
drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.h
create mode 100644
drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_report_descriptor.h
diff --git a/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.c
b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.c
new file mode 100644
index ..dc87c0547874
--- /dev/null
+++ b/drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * AMD SFH Report Descriptor generator logic
+ * Copyright 2020 Advanced Micro Devices, Inc.
+ * Authors: Nehal Bakulchandra Shah
+ * Sandeep Singh
+ */
+
+#include
+#include
+#include
+#include "amd_sfh_hid_descriptor.h"
+#include "amd_sfh_hid_report_descriptor.h"
+#include "amd_mp2_pcie.h"
+
+#defineAMD_SFH_FW_MULTIPLIER (1000)
+#define HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM 0x41
+#define HID_USAGE_SENSOR_PROP_POWER_STATE_D0_FULL_POWER_ENUM 0x51
+#define HID_DEFAULT_REPORT_INTERVAL0x50
+#define HID_DEFAULT_MIN_VALUE 0X7F
+#define HID_DEFAULT_MAX_VALUE 0x80
+#define HID_DEFAULT_SENSITIVITY0x7F
+#define HID_USAGE_SENSOR_PROPERTY_CONNECTION_TYPE_PC_INTEGRATED_ENUM 0x01
+/* state enums */
+#define HID_USAGE_SENSOR_STATE_READY_ENUM 0x02
+#define HID_USAGE_SENSOR_STATE_INITIALIZING_ENUM 0x05
+#define HID_USAGE_SENSOR_EVENT_DATA_UPDATED_ENUM 0x04
+
+int get_report_descriptor(int sensor_idx, u8 *rep_desc)
+{
+ switch (sensor_idx) {
+ case accel_idx: /* accel */
+ memset(rep_desc, 0, sizeof(accel3_report_descriptor));
+ memcpy(rep_desc, accel3_report_descriptor,
+ sizeof(accel3_report_descriptor));
+ break;
+ case gyro_idx: /* gyro */
+ memset(rep_desc, 0, sizeof(gyro3_report_descriptor));
+ memcpy(rep_desc, gyro3_report_descriptor,
+ sizeof(gyro3_report_descriptor));
+ break;
+ case mag_idx: /* Magnetometer */
+ memset(rep_desc, 0, sizeof(comp3_report_descriptor));
+ memcpy(rep_desc, comp3_report_descriptor,
+ sizeof(comp3_report_descriptor));
+ break;
+ case als_idx: /* ambient light sensor */
+ memset(rep_desc, 0, sizeof(als_report_descriptor));
+ memcpy(rep_desc, als_report_descriptor,
+ sizeof(als_report_descriptor));
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+u32 get_descr_sz(int sensor_idx, int descriptor_name)
+{
+ switch (sensor_idx) {
+ case accel_idx:
+ switch (descriptor_name) {
+ case descr_size:
+ return sizeof(accel3_report_descriptor);
+ case input_size:
+ return sizeof(struct accel3_input_report);
+ case feature_size:
+ return sizeof(struct accel3_feature_report);
+ }
+ break;
+ case gyro_idx:
+ switch (descriptor_name) {
+ case descr_size:
+ return sizeof(gyro3_report_descriptor);
+ case input_size:
+ return sizeof(struct gyro_input_report);
+ case feature_size:
+ return sizeof(struct gyro_feature_report);
+ }
+ break;
+ case mag_idx:
+ switch (descriptor_name) {
+ case descr_size:
+ return sizeof(comp3_report_descriptor);
+ case input_size:
+ return sizeof(struct magno_input_report);
+ case feature_size:
+ return sizeof(struct magno_feature_report);
+ }
+ break;
+ case als_idx:
+ switch (descriptor_name) {
+ case descr_size:
+ return sizeof(als_report_descriptor);
+ case input_size:
+ return sizeof(struct als_input_report);
+ case feature_size:
+
[PATCH v6 3/4] SFH: Transport Driver to add support of AMD Sensor Fusion Hub (SFH)
From: Sandeep Singh
This part of module will provide the interaction between HID framework
and client layer.This modules will registered client layer with
HID framework.
Signed-off-by: Nehal Shah
Signed-off-by: Sandeep Singh
---
drivers/hid/amd-sfh-hid/amdsfh_hid.c| 175
drivers/hid/amd-sfh-hid/amdsfh_hid.h| 68 ++
drivers/hid/amd-sfh-hid/amdsfh_hid_client.c | 220
3 files changed, 463 insertions(+)
create mode 100644 drivers/hid/amd-sfh-hid/amdsfh_hid.c
create mode 100644 drivers/hid/amd-sfh-hid/amdsfh_hid.h
create mode 100644 drivers/hid/amd-sfh-hid/amdsfh_hid_client.c
diff --git a/drivers/hid/amd-sfh-hid/amdsfh_hid.c
b/drivers/hid/amd-sfh-hid/amdsfh_hid.c
new file mode 100644
index ..645c41174bca
--- /dev/null
+++ b/drivers/hid/amd-sfh-hid/amdsfh_hid.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * AMD MP2 Sensors transport driver
+ *
+ * Authors: Nehal Bakulchandra Shah
+ * Sandeep Singh
+ */
+#include
+#include
+#include
+#include "amdsfh_hid.h"
+
+#define DRIVER_NAME "AMD_MP2_SENSORS_TRANSPORT"
+
+/*
+ * amdtp_hid_parse() - hid-core .parse() callback
+ * @hid: hid device instance
+ *
+ * This function gets called during call to hid_add_device
+ *
+ * Return: 0 on success and non zero on error
+ */
+static int amdtp_hid_parse(struct hid_device *hid)
+{
+ struct amdtp_hid_data *hid_data = hid->driver_data;
+ struct amdtp_cl_data *cli_data = hid_data->cli_data;
+
+ return hid_parse_report(hid, cli_data->report_descr[hid_data->index],
+ cli_data->report_descr_sz[hid_data->index]);
+}
+
+/* Empty callbacks with success return code */
+static int amdtp_hid_start(struct hid_device *hid)
+{
+ return 0;
+}
+
+static void amdtp_hid_stop(struct hid_device *hid)
+{
+}
+
+static int amdtp_hid_open(struct hid_device *hid)
+{
+ return 0;
+}
+
+static void amdtp_hid_close(struct hid_device *hid)
+{
+}
+
+static int amdtp_raw_request(struct hid_device *hdev, u8 reportnum,
+u8 *buf, size_t len, u8 rtype, int reqtype)
+{
+ return 0;
+}
+
+static void amdtp_hid_request(struct hid_device *hid, struct hid_report *rep,
int reqtype)
+{
+ int rc;
+
+ switch (reqtype) {
+ case HID_REQ_GET_REPORT:
+ rc = amd_sfh_get_report(hid, rep->id, rep->type);
+ if (rc)
+ pr_err("AMDSFH get report error ");
+ break;
+ case HID_REQ_SET_REPORT:
+ amd_sfh_set_report(hid, rep->id, reqtype);
+ break;
+ default:
+ break;
+ }
+}
+
+static int amdtp_wait_for_response(struct hid_device *hid)
+{
+ struct amdtp_hid_data *hid_data = hid->driver_data;
+ struct amdtp_cl_data *cli_data = hid_data->cli_data;
+ int i, ret = 0;
+
+ for (i = 0; i < cli_data->num_hid_devices; i++) {
+ if (cli_data->hid_sensor_hubs[i] == hid)
+ break;
+ }
+
+ if (!cli_data->request_done[i])
+ ret = wait_event_interruptible_timeout(hid_data->hid_wait,
+
cli_data->request_done[i], 1500);
+ if (ret > 0)
+ return 0;
+ else if (ret == -ERESTARTSYS)
+ return -ERESTARTSYS;
+ else
+ return -ETIMEDOUT;
+}
+
+void amdtp_hid_wakeup(struct hid_device *hid)
+{
+ struct amdtp_hid_data *hid_data = hid->driver_data;
+ struct amdtp_cl_data *cli_data = hid_data->cli_data;
+
+ cli_data->request_done[cli_data->cur_hid_dev] = true;
+ wake_up_interruptible(_data->hid_wait);
+}
+
+static struct hid_ll_driver amdtp_hid_ll_driver = {
+ .parse = amdtp_hid_parse,
+ .start = amdtp_hid_start,
+ .stop = amdtp_hid_stop,
+ .open = amdtp_hid_open,
+ .close = amdtp_hid_close,
+ .request = amdtp_hid_request,
+ .wait = amdtp_wait_for_response,
+ .raw_request = amdtp_raw_request,
+};
+
+int amdtp_hid_probe(u32 cur_hid_dev,
+ struct amdtp_cl_data *cli_data)
+{
+ struct hid_device *hid;
+ struct amdtp_hid_data *hid_data;
+ int rc;
+
+ hid = hid_allocate_device();
+ if (IS_ERR(hid)) {
+ rc = PTR_ERR(hid);
+ return rc;
+ }
+
+ hid_data = kzalloc(sizeof(*hid_data), GFP_KERNEL);
+ if (!hid_data) {
+ rc = -ENOMEM;
+ goto err_hid_data;
+ }
+
+ hid->ll_driver = _hid_ll_driver;
+ hid_data->index = cur_hid_dev;
+ hid_data->cli_data = cli_data;
+ init_waitqueue_head(_data->hid_wait);
+
+ hid->driver_data = hid_data;
+ cli_data->hid_sensor_hubs[cur_hid_dev] = hid;
+ hid->bus = BUS_AMD_AMDTP;
+ hid->vendor = AMD_SFH_HID_VENDOR;
+ hid->product = AMD_SFH_HID_PRODUCT;
+
[PATCH v6 0/4] SFH: Add Support for AMD Sensor Fusion Hub
From: Sandeep Singh AMD SFH(Sensor Fusion Hub) is HID based driver.SFH FW is part of MP2 processor (MP2 which is an ARM® Cortex-M4 core based co-processor to x86) and it runs on MP2 where in driver resides on X86.The driver functionalities are divided into three parts:- 1: amd-mp2-pcie:- This module will communicate with MP2 FW and provide that data into DRAM. 2: Client Layer:- This part for driver will use dram data and convert that data into HID format based on HID reports. 3: Transport driver :- This part of driver will communicate with HID core. Communication between devices and HID core is mostly done via HID reports In terms of architecture, it resembles like ISH(Intel Integrated Sensor Hub).However the major difference is all the hid reports are generated as part of kernel driver. AMD SFH is integrated as a part of SoC, starting from 17h family of processors. The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus. Changes since v1: -> Fix auto build test warnings -> Fix smatch warnings "possible memory leak" -Reported by Dan Carpenter Links of the review comments for v1: [1] https://patchwork.kernel.org/patch/11325163/ [2] https://patchwork.kernel.org/patch/11325167/ [3] https://patchwork.kernel.org/patch/11325171/ [4] https://patchwork.kernel.org/patch/11325187/ Changes since v2: -> Debugfs divided into another patch -> Fix some cosmetic changes -> Fix for review comments Reported and Suggested by:- Srinivas Pandruvada Links of the review comments for v2: [1] https://patchwork.kernel.org/patch/11355491/ [2] https://patchwork.kernel.org/patch/11355495/ [3] https://patchwork.kernel.org/patch/11355499/ [4] https://patchwork.kernel.org/patch/11355503/ Changes since v3: -> Removed debugfs suggested by - Benjamin Tissoires Links of the review comments for v3: [1] https://lkml.org/lkml/2020/2/11/1256 [2] https://lkml.org/lkml/2020/2/11/1257 [3] https://lkml.org/lkml/2020/2/11/1258 [4] https://lkml.org/lkml/2020/2/11/1259 [5] https://lkml.org/lkml/2020/2/11/1260 Changes since v4: -> use PCI managed calls. -> use kernel APIs Links of the review comments for v4: [1] https://lkml.org/lkml/2020/2/26/1360 [2] https://lkml.org/lkml/2020/2/26/1361 [3] https://lkml.org/lkml/2020/2/26/1362 [4] https://lkml.org/lkml/2020/2/26/1363 [5] https://lkml.org/lkml/2020/2/27/1 Changes since v5 - Fix for review comments by: Andy Shevchenko - Fix for indentations erros, NULL pointer,Redundant assignment - Drop LOCs in many location - Create as a single driver module instead of two modules. Links of the review comments for v5: [1] https://lkml.org/lkml/2020/5/29/589 [2] https://lkml.org/lkml/2020/5/29/590 [3] https://lkml.org/lkml/2020/5/29/606 [4] https://lkml.org/lkml/2020/5/29/632 [5] https://lkml.org/lkml/2020/5/29/633 Sandeep Singh (4): SFH: Add maintainers and documentation for AMD SFH based on HID framework SFH: PCIe driver to add support of AMD sensor fusion SFH: Transport Driver to add support of AMD Sensor Fusion Hub (SFH) SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH) Documentation/hid/amd-sfh-hid.rst | 153 + MAINTAINERS | 8 + drivers/hid/Kconfig | 2 + drivers/hid/Makefile | 2 + drivers/hid/amd-sfh-hid/Kconfig | 21 + drivers/hid/amd-sfh-hid/Makefile | 15 + drivers/hid/amd-sfh-hid/amd_mp2_pcie.c| 162 + drivers/hid/amd-sfh-hid/amd_mp2_pcie.h| 83 +++ drivers/hid/amd-sfh-hid/amdsfh_hid.c | 175 + drivers/hid/amd-sfh-hid/amdsfh_hid.h | 68 ++ drivers/hid/amd-sfh-hid/amdsfh_hid_client.c | 220 ++ .../hid_descriptor/amd_sfh_hid_descriptor.c | 226 ++ .../hid_descriptor/amd_sfh_hid_descriptor.h | 121 .../amd_sfh_hid_report_descriptor.h | 645 ++ 14 files changed, 1901 insertions(+) create mode 100644 Documentation/hid/amd-sfh-hid.rst create mode 100644 drivers/hid/amd-sfh-hid/Kconfig create mode 100644 drivers/hid/amd-sfh-hid/Makefile create mode 100644 drivers/hid/amd-sfh-hid/amd_mp2_pcie.c create mode 100644 drivers/hid/amd-sfh-hid/amd_mp2_pcie.h create mode 100644 drivers/hid/amd-sfh-hid/amdsfh_hid.c create mode 100644 drivers/hid/amd-sfh-hid/amdsfh_hid.h create mode 100644 drivers/hid/amd-sfh-hid/amdsfh_hid_client.c create mode 100644 drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.c create mode 100644 drivers/hid/amd-sfh-hid/hid_descriptor/amd_sfh_hid_descriptor.h create mode 100644
[PATCH v6 1/4] SFH: Add maintainers and documentation for AMD SFH based on HID framework
From: Sandeep Singh Add Maintainers for AMD SFH(SENSOR FUSION HUB) Solution and work flow document. Signed-off-by: Nehal Shah Signed-off-by: Sandeep Singh --- Documentation/hid/amd-sfh-hid.rst | 153 ++ MAINTAINERS | 8 ++ 2 files changed, 161 insertions(+) create mode 100644 Documentation/hid/amd-sfh-hid.rst diff --git a/Documentation/hid/amd-sfh-hid.rst b/Documentation/hid/amd-sfh-hid.rst new file mode 100644 index ..0ee9003013f2 --- /dev/null +++ b/Documentation/hid/amd-sfh-hid.rst @@ -0,0 +1,153 @@ +.. SPDX-License-Identifier: GPL-2.0 + +AMD Sensor Fusion Hub:- +== +AMD Sensor Fusion Hub is part of a SOC starting from Ryzen based platforms. +The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus. +In terms of architecture it resembles ISH .However the major difference is all +The hid reports are generated as part of kernel driver. + +Block Diagram:- += + --- + | HID User Space Applications | + --- +- +- + | HID Core | +- + +- + | AMD HID Transport | +- + + + | AMD HID Client | + | with HID Report Generator| + + + + | AMD MP2 PCIe Driver | + +- + --- + | SFH MP2 Processor | + + + +AMD HID Transport Layer :- +*** +AMD SFH transport is also implemented as a bus. Each client application executing in the AMD MP2 +is registered as a device on this bus. MP2 which is an ARM® Cortex-M4 core based co-processor to +x86. The driver, which binds each device (AMD SFH HID driver) identifies the device type and +registers with the hid core. Transport drivers attach a constant "struct hid_ll_driver" object with +each device. Once a device is registered with HID core, the callbacks provided via this struct are +used by HID core to communicate with the device. AMD HID Transport driver implements the synchronouscalls. + +AMD HID Client Layer:- +** +This layer is responsible to implement HID request and descriptors. As firmware is OS agnostic, +HID client layer fills the HID request structure and descriptors. HID client layer is in complex +in nature as it is interface between MP2 PCIe driver and HID. HID client layer initialized +the MP2 PCIe driver and holds the instance of MP2 driver.It identified the number of sensors +connected using MP2-PCIe driver and based on that allocate the DRAM address for each and every +sensor and pass it to MP2-PCIe driver.On enumeration of each sensor, client layer fills out the HID +Descriptor structure and HID input report structure. HID Feature report structure can be optional. +The report descriptor structure varies sensor to sensor. Now on enumeration client layer does +two major things +1. Register the HID sensor client to virtual bus (Platform driver) and bind it. +2. Probes the AMD HID transport driver. Which in turns register device to the core. + +AMD MP2 PCIe layer:- + +MP2 PCIe Layer is responsible for making all transaction with the firmware over PCIe. +The connection establishment between firmware and PCIe happens here. + +The communication between X86 and MP2 is spilt into three parts. +1. Command Transfer => C2P Mailbox Register are used +2. Data Transfer => DRAM +3. Supported sensor info => P2C Register + +Commands are sent to MP2 using C2P Mail Box registers. These C2P registers are common between x86 +and MP2. Writing into C2P Message register generate interrupt to MP2. The client layer allocates +the physical memory and send the same to MP2 for data transfer. MP2 firmware uses HUBIF interface +to access DRAM memory. For Firmware always write minimum 32 bytes into DRAM.So it is expected that +driver shall allocate minimum 32 bytes DRAM space. + +Enumeration and Probing flow:- +* + HID AMDAMD AMD -PCIe MP2 + Core Transport Client layer layer FW + | | | | | + | | | on Boot Driver Loaded | + | | | | | + | |
Re: [PATCH][next] habanalabs: fix incorrect check on failed workqueue create
On Fri, Jul 31, 2020 at 9:21 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jul 30, 2020 at 01:51:48PM +0300, Oded Gabbay wrote:
> > On Thu, Jul 30, 2020 at 11:20 AM Colin King
> > wrote:
> > >
> > > From: Colin Ian King
> > >
> > > The null check on a failed workqueue create is currently null checking
> > > hdev->cq_wq rather than the pointer hdev->cq_wq[i] and so the test
> > > will never be true on a failed workqueue create. Fix this by checking
> > > hdev->cq_wq[i].
> > >
> > > Addresses-Coverity: ("Dereference before null check")
> > > Fixes: 5574cb2194b1 ("habanalabs: Assign each CQ with its own work queue")
> > > Signed-off-by: Colin Ian King
> > > ---
> > > drivers/misc/habanalabs/common/device.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/misc/habanalabs/common/device.c
> > > b/drivers/misc/habanalabs/common/device.c
> > > index be16b75bdfdb..35214a186913 100644
> > > --- a/drivers/misc/habanalabs/common/device.c
> > > +++ b/drivers/misc/habanalabs/common/device.c
> > > @@ -288,7 +288,7 @@ static int device_early_init(struct hl_device *hdev)
> > > for (i = 0 ; i < hdev->asic_prop.completion_queues_count ; i++) {
> > > snprintf(workq_name, 32, "hl-free-jobs-%u", i);
> > > hdev->cq_wq[i] =
> > > create_singlethread_workqueue(workq_name);
> > > - if (hdev->cq_wq == NULL) {
> > > + if (hdev->cq_wq[i] == NULL) {
> > > dev_err(hdev->dev, "Failed to allocate CQ
> > > workqueue\n");
> > > rc = -ENOMEM;
> > > goto free_cq_wq;
> > > --
> > > 2.27.0
> > >
> >
> > This patch is:
> > Reviewed-by: Oded Gabbay
> >
> > Greg, can you please apply it directly to the char-misc-next branch ?
> > I don't want to send a pull request for 1 patch.
>
> Already merged :)
Hi Greg,
I can't find this patch in char-misc-next.
Can you please check if you applied it ?
If not, I'll apply it to my fixes tree and send it to you for -rc2
Thanks,
Oded
[PATCH] staging: ks7010: Do not use GFP_KERNEL in atomic context
A possible call chain is as follow:
ks_wlan_start_xmit(ks_wlan_net.c)
--> hostif_data_request (ks_hostif.c)
--> michael_mic (ks_hostif.c)
'ks_wlan_start_xmit()' is a '.ndo_start_xmit()' function (see
net_device_ops structure). Such calls are guarded by the __netif_tx_lock
spinlock. So memory allocation must be atomic.
So, use GFP_ATOMIC instead of GFP_KERNEL 'in michael_mic()'
Fixes: ???
Signed-off-by: Christophe JAILLET
---
This is completely speculative. I don't know if the call chain given above
if possible in RL application.
So review carefully :)
If the fix is correct, it is also more the starting point of a bigger
change, because in 'michael_mic()' there is a call to
'crypto_alloc_shash()' and this function uses GFP_KERNEL internally (in
'crypto_create_tfm()')
Should this need to be changed, I don't know how 'ks_hostif.c' should be
fixed. Changing allocation in 'crypto/api.c' looks like an overkill.
In other word, I think that my patch is wrong, but don't know what else to
propose :).
---
drivers/staging/ks7010/ks_hostif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index d70b671b06aa..c66f50e4a158 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -212,7 +212,7 @@ michael_mic(u8 *key, u8 *data, unsigned int len, u8
priority, u8 *result)
if (ret < 0)
goto err_free_tfm;
- desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(tfm), GFP_KERNEL);
+ desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(tfm), GFP_ATOMIC);
if (!desc) {
ret = -ENOMEM;
goto err_free_tfm;
--
2.25.1
[PATCH] MAINTAINERS: Change OmniKey CM40xx drivers to Orphan state
From: Harald Welte I haven't been doing any work on those drivers in ages, neither do I even use any related devices. Signed-off-by: Harald Welte --- MAINTAINERS | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f77df02e4121..05f5eb227700 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12694,15 +12694,13 @@ F:Documentation/filesystems/omfs.rst F: fs/omfs/ OMNIKEY CARDMAN 4000 DRIVER -M: Harald Welte -S: Maintained +S: Orphan F: drivers/char/pcmcia/cm4000_cs.c F: include/linux/cm4000_cs.h F: include/uapi/linux/cm4000_cs.h OMNIKEY CARDMAN 4040 DRIVER -M: Harald Welte -S: Maintained +S: Orphan F: drivers/char/pcmcia/cm4040_cs.* OMNIVISION OV13858 SENSOR DRIVER -- 2.28.0
Re: [PATCH] Coccinelle: Reduce duplicate code for patch rules of memdup_user.cocci
On Sun, 9 Aug 2020, Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 9 Aug 2020 11:11:20 +0200
>
> Another patch rule was added. A bit of code was copied from a previous
> SmPL rule for this change specification.
>
> * Thus reduce duplicate code by using another SmPL disjunction.
I don't care about this issue.
>
> * Increase the precision a bit for desired source code adjustments.
This gives no information. If you explain the improvement in an
understandable way, I will consider whether it is useful to take the
patch.
julia
> Fixes: 9c568dbd677bcfc975220d3157c89c48669a23e3 ("coccinelle: api: extend
> memdup_user rule with vmemdup_user()")
> Signed-off-by: Markus Elfring
> ---
> scripts/coccinelle/api/memdup_user.cocci | 44 +---
> 1 file changed, 16 insertions(+), 28 deletions(-)
>
> diff --git a/scripts/coccinelle/api/memdup_user.cocci
> b/scripts/coccinelle/api/memdup_user.cocci
> index e01e95108405..7cf698b4e925 100644
> --- a/scripts/coccinelle/api/memdup_user.cocci
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -27,34 +27,22 @@ expression from,to,size;
> identifier l1,l2;
> position p : script:python() { relevant(p) };
> @@
> -
> -- to = \(kmalloc@p\|kzalloc@p\)
> --(size,\(GFP_KERNEL\|GFP_USER\|
> -- \(GFP_KERNEL\|GFP_USER\)|__GFP_NOWARN\));
> -+ to = memdup_user(from,size);
> - if (
> -- to==NULL
> -+ IS_ERR(to)
> - || ...) {
> - <+... when != goto l1;
> -- -ENOMEM
> -+ PTR_ERR(to)
> - ...+>
> - }
> -- if (copy_from_user(to, from, size) != 0) {
> --<+... when != goto l2;
> ---EFAULT
> --...+>
> -- }
> -
> -@depends on patch@
> -expression from,to,size;
> -identifier l1,l2;
> -position p : script:python() { relevant(p) };
> -@@
> -
> -- to = \(kvmalloc@p\|kvzalloc@p\)(size,\(GFP_KERNEL\|GFP_USER\));
> -+ to = vmemdup_user(from,size);
> + to =
> +(
> +- \(kmalloc@p\|kzalloc@p\)
> ++ memdup_user
> + (
> +- size, \( \(GFP_KERNEL\|GFP_USER\) \|
> \(GFP_KERNEL\|GFP_USER\)|__GFP_NOWARN \)
> ++ from, size
> + )
> +|
> +- \(kvmalloc@p\|kvzalloc@p\)
> ++ vmemdup_user
> + (
> +- size, \(GFP_KERNEL\|GFP_USER\)
> ++ from, size
> + )
> +);
> if (
> - to==NULL
> + IS_ERR(to)
> --
> 2.28.0
>
>
Re: [PATCH] iio: documentation: light: Add as73211 sysfs documentation
On Sun, 9 Aug 2020 09:43:35 +0200 Christian Eggers wrote: > The driver for the as73211 light sensor provides the following not yet > documented sysfs entries: > - in_intensity_(x|y|z)_raw > - in_intensity_(x|y|z)_scale > - in_intensity_sampling_frequency(_available) > - in_intensity_hardwaregain(_available) > - in_intensity_integration_time > > Signed-off-by: Christian Eggers Hi Christian, Just one tiny nitpick. Otherwise looks good to me! Thanks for doing this, Jonathan > --- > > On Thursday, 6 August 2020, 19:44:51 CEST, Jonathan Cameron wrote: > Hi Jonathan, > > > Hi Christian, > > > > I'll take this, but please send a follow up patch to add documentation > > for in_intensity_x_raw and all the other new ABI this adds in > > Documentation/ABI/testing/sysfs-bus-iio > > I should have mentioned that earlier, but kind of assumed we already > > had these documented for some reason! > > [...] > > Insert them into the relevant groups that already exist. In some cases > > it will just be adding an entry with no specific explanation. > > For the _raw attribute add a bit more info about what x, y and z are > > (basically just say they are from cie1931 (I think?) > > I added all sysfs entries which were not present in 5.8-rc6. > > Best regards > Christian > > Documentation/ABI/testing/sysfs-bus-iio | 26 - > 1 file changed, 25 insertions(+), 1 deletion(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > b/Documentation/ABI/testing/sysfs-bus-iio > index d3e53a6d8331..14ae4bf053c5 100644 > --- a/Documentation/ABI/testing/sysfs-bus-iio > +++ b/Documentation/ABI/testing/sysfs-bus-iio > @@ -40,6 +40,7 @@ Description: > buffered samples and events for device X. > > What:/sys/bus/iio/devices/iio:deviceX/sampling_frequency > +What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency > What: > /sys/bus/iio/devices/iio:deviceX/buffer/sampling_frequency > What:/sys/bus/iio/devices/triggerX/sampling_frequency > KernelVersion: 2.6.35 > @@ -55,6 +56,7 @@ Description: > then it is to be found in the base device directory. > > What: > /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available > +What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_sampling_frequency_available > What: > /sys/bus/iio/devices/iio:deviceX/in_proximity_sampling_frequency_available > What:/sys/.../iio:deviceX/buffer/sampling_frequency_available > What: > /sys/bus/iio/devices/triggerX/sampling_frequency_available > @@ -374,6 +376,9 @@ What: > /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale > What:/sys/bus/iio/devices/iio:deviceX/in_illuminance_scale > What:/sys/bus/iio/devices/iio:deviceX/in_countY_scale > What:/sys/bus/iio/devices/iio:deviceX/in_angl_scale > +What:/sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale > +What:/sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale > +What:/sys/bus/iio/devices/iio:deviceX/in_intensity_z_scale > KernelVersion: 2.6.35 > Contact: linux-...@vger.kernel.org > Description: > @@ -484,6 +489,7 @@ Description: > are listed in this attribute. > > What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain > +What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_hardwaregain > What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain > What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain > What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain > @@ -494,6 +500,13 @@ Description: > Hardware applied gain factor. If shared across all channels, > _hardwaregain is used. > > +What: > /sys/bus/iio/devices/iio:deviceX/in_intensity_hardwaregain_available > +KernelVersion: 5.10 > +Contact: linux-...@vger.kernel.org > +Description: > + Lists all available hardware applied gain factors. Shared > across all > + channels. > + > What:/sys/.../in_accel_filter_low_pass_3db_frequency > What:/sys/.../in_magn_filter_low_pass_3db_frequency > What:/sys/.../in_anglvel_filter_low_pass_3db_frequency > @@ -1333,6 +1346,7 @@ Description: > standardised CIE Erythemal Action Spectrum. UV index values > range > from 0 (low) to >=11 (extreme). > > +What:/sys/.../iio:deviceX/in_intensity_integration_time > What:/sys/.../iio:deviceX/in_intensity_red_integration_time > What:/sys/.../iio:deviceX/in_intensity_green_integration_time > What:
Re: [PATCH] iio:temperature:mlx90632: Some stylefixing leftovers
On Thu, 6 Aug 2020 23:21:39 +0200
Crt Mori wrote:
> There is some inconsistency and whitespace cleanup performed in this
> patch. It was done on top of my other patches, but I can rebase to head
> of the togreg branch if it would go in sooner.
>
> Signed-off-by: Crt Mori
If not already done so, probably just add this to the other series.
If you prefer to keep it separate then remind me if I seem to have
lost this one after those patches are in place.
Thanks,
Jonathan
> ---
> drivers/iio/temperature/mlx90632.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/temperature/mlx90632.c
> b/drivers/iio/temperature/mlx90632.c
> index bb35a65bb9f0..d966e5387c48 100644
> --- a/drivers/iio/temperature/mlx90632.c
> +++ b/drivers/iio/temperature/mlx90632.c
> @@ -100,10 +100,10 @@
> #define MLX90632_DSP_VERSION 5 /* DSP version */
> #define MLX90632_DSP_MASKGENMASK(7, 0) /* DSP version in EE_VERSION */
> #define MLX90632_RESET_CMD 0x0006 /* Reset sensor (address or global) */
> -#define MLX90632_REF_12 12LL /**< ResCtrlRef value of Ch 1 or
> Ch 2 */
> -#define MLX90632_REF_3 12LL /**< ResCtrlRef value of Channel 3
> */
> -#define MLX90632_MAX_MEAS_NUM31 /**< Maximum measurements in list */
> -#define MLX90632_SLEEP_DELAY_MS 3000 /**< Autosleep delay */
> +#define MLX90632_REF_12 12LL /* ResCtrlRef value of Ch 1 or Ch 2 */
> +#define MLX90632_REF_3 12LL /* ResCtrlRef value of Channel 3 */
> +#define MLX90632_MAX_MEAS_NUM31 /* Maximum measurements in list */
> +#define MLX90632_SLEEP_DELAY_MS 3000 /* Autosleep delay */
> #define MLX90632_EXTENDED_LIMIT 27000 /* Extended mode raw value limit */
>
> struct mlx90632_data {
> @@ -884,7 +884,7 @@ static int mlx90632_probe(struct i2c_client *client,
> mlx90632->mtyp = MLX90632_MTYP_EXTENDED;
> } else if ((read & MLX90632_DSP_MASK) == MLX90632_DSP_VERSION) {
> dev_dbg(>dev,
> - "Detected Unknown EEPROM calibration %x\n", read);
> + "Detected Unknown EEPROM calibration %x\n", read);
> } else {
> dev_err(>dev,
> "Wrong DSP version %x (expected %x)\n",
Re: [PATCH] iio: adc: rockchip_saradc: select IIO_TRIGGERED_BUFFER
On Mon, 03 Aug 2020 13:59:12 +0200
Heiko Stuebner wrote:
> Am Montag, 3. August 2020, 10:30:01 CEST schrieb Michael Walle:
> > The kernel fails to compile due to undefined reference to
> > devm_iio_triggered_buffer_setup() if IIO_TRIGGERED_BUFFER is not
> > enabled. The original patch [1] had this dependency. But somehow it
> > didn't make it into the kernel tree. Re-add it.
> >
> > [1] https://lore.kernel.org/lkml/20200623233011.2319035-3-he...@sntech.de/
> >
> > Fixes: 4e130dc7b413 ("iio: adc: rockchip_saradc: Add support iio buffers")
> > Signed-off-by: Michael Walle
>
> Reviewed-by: Heiko Stuebner
Applied to the fixes-togreg branch of iio.git.
Thanks,
Jonathan
>
> > ---
> > drivers/iio/adc/Kconfig | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 66d9cc073157..d94dc800b842 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -865,6 +865,8 @@ config ROCKCHIP_SARADC
> > tristate "Rockchip SARADC driver"
> > depends on ARCH_ROCKCHIP || (ARM && COMPILE_TEST)
> > depends on RESET_CONTROLLER
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > help
> > Say yes here to build support for the SARADC found in SoCs from
> > Rockchip.
> >
>
>
>
>
Non-deterministically boot into dark screen with `amdgpu`
Hello! This is an issue report. I am not familiar with the Linux kernel development procedure, so please direct me to a more appropriate or specialized medium if this is not the right avenue. My laptop (Ryzen 7 Pro CPU/GPU) boots into dark screen more often than not. Screen blackness correlates with a line in the `systemd` journal that says `RAM width Nbits DDR4`, where N is either 128 (resulting in dark screen) or 64 (resulting in a healthy boot). The number seems to be chosen at random with bias towards 128. This has been going on for a while so here is some statistics: * 356 boots proceed far enough to attempt mode setting. * 82 boots set RAM width to 64 bits and presumably succeed. * 274 boots set RAM width to 128 bits and presumably fail. The issue is prevented with the `nomodeset` kernel option. I reported this previously (about a year ago) on the forum of my Linux distribution.[1] The issue still persists as of linux 5.8.0. The details of my graphics controller, as well as some journal excerpts, can be seen at [1]. One thing that has changed since then is that on failure, there now appears a null pointer dereference error. I am attaching the log of kernel messages from the most recent failed boot — please request more information if needed. I appreciate any directions and advice as to how I may go about fixing this annoyance. [1]: https://bbs.archlinux.org/viewtopic.php?id=248273 Linux version 5.8.0-1-next-git (linux-next-git@archlinux) (gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34.0) #2 SMP PREEMPT Sun, 09 Aug 2020 10:52:48 + Command line: initrd=\initramfs-linux-next-git.img root=/dev/lvm/system-arch KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Hygon HygonGenuine Centaur CentaurHauls zhaoxin Shanghai x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009] usable BIOS-e820: [mem 0x0010-0x03ff] usable BIOS-e820: [mem 0x0400-0x04009fff] ACPI NVS BIOS-e820: [mem 0x0400a000-0x79e2] usable BIOS-e820: [mem 0x79e3-0x7ac2] reserved BIOS-e820: [mem 0x7ac3-0x7b32] ACPI NVS BIOS-e820: [mem 0x7b33-0x7b3a] ACPI data BIOS-e820: [mem 0x7b3b-0x8dff] usable BIOS-e820: [mem 0xf800-0xfbff] reserved BIOS-e820: [mem 0xfec0-0xfec00fff] reserved BIOS-e820: [mem 0xfec1-0xfec10fff] reserved BIOS-e820: [mem 0xfed8-0xfed80fff] reserved BIOS-e820: [mem 0xfedf1000-0xfedf1fff] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xff00-0x] reserved BIOS-e820: [mem 0x0001-0x00022f33] usable NX (Execute Disable) protection: active e820: update [mem 0x6a229018-0x6a239057] usable ==> usable e820: update [mem 0x6a229018-0x6a239057] usable ==> usable e820: update [mem 0x6a21b018-0x6a228457] usable ==> usable e820: update [mem 0x6a21b018-0x6a228457] usable ==> usable extended physical RAM map: reserve setup_data: [mem 0x-0x0009] usable reserve setup_data: [mem 0x0010-0x03ff] usable reserve setup_data: [mem 0x0400-0x04009fff] ACPI NVS reserve setup_data: [mem 0x0400a000-0x6a21b017] usable reserve setup_data: [mem 0x6a21b018-0x6a228457] usable reserve setup_data: [mem 0x6a228458-0x6a229017] usable reserve setup_data: [mem 0x6a229018-0x6a239057] usable reserve setup_data: [mem 0x6a239058-0x79e2] usable reserve setup_data: [mem 0x79e3-0x7ac2] reserved reserve setup_data: [mem 0x7ac3-0x7b32] ACPI NVS reserve setup_data: [mem 0x7b33-0x7b3a] ACPI data reserve setup_data: [mem 0x7b3b-0x8dff] usable reserve setup_data: [mem 0xf800-0xfbff] reserved reserve setup_data: [mem 0xfec0-0xfec00fff] reserved reserve setup_data: [mem 0xfec1-0xfec10fff] reserved reserve setup_data: [mem 0xfed8-0xfed80fff] reserved reserve setup_data: [mem 0xfedf1000-0xfedf1fff] reserved reserve setup_data: [mem 0xfee0-0xfee00fff] reserved reserve setup_data: [mem 0xff00-0x] reserved reserve setup_data: [mem 0x0001-0x00022f33] usable efi: EFI v2.50 by HP efi: ACPI=0x7b3af000 ACPI 2.0=0x7b3af014 SMBIOS=0x7a52b000 SMBIOS
[PATCH 2/4] habanalabs: set clock gating according to mask
From: Ofir Bitton
Once clock gating is set we enable clock gating according to mask,
we should also disable clock gating according to relevant bits.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/gaudi/gaudi.c | 44 +--
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 08124873483f..7e0f9f64ffcb 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -2508,6 +2508,7 @@ static void gaudi_set_clock_gating(struct hl_device *hdev)
{
struct gaudi_device *gaudi = hdev->asic_specific;
u32 qman_offset;
+ bool enable;
int i;
/* In case we are during debug session, don't enable the clock gate
@@ -2517,46 +2518,43 @@ static void gaudi_set_clock_gating(struct hl_device
*hdev)
return;
for (i = GAUDI_PCI_DMA_1, qman_offset = 0 ; i < GAUDI_HBM_DMA_1 ; i++) {
- if (!(hdev->clock_gating_mask &
- (BIT_ULL(gaudi_dma_assignment[i]
- continue;
+ enable = !!(hdev->clock_gating_mask &
+ (BIT_ULL(gaudi_dma_assignment[i])));
qman_offset = gaudi_dma_assignment[i] * DMA_QMAN_OFFSET;
- WREG32(mmDMA0_QM_CGM_CFG1 + qman_offset, QMAN_CGM1_PWR_GATE_EN);
+ WREG32(mmDMA0_QM_CGM_CFG1 + qman_offset,
+ enable ? QMAN_CGM1_PWR_GATE_EN : 0);
WREG32(mmDMA0_QM_CGM_CFG + qman_offset,
- QMAN_UPPER_CP_CGM_PWR_GATE_EN);
+ enable ? QMAN_UPPER_CP_CGM_PWR_GATE_EN : 0);
}
for (i = GAUDI_HBM_DMA_1 ; i < GAUDI_DMA_MAX ; i++) {
- if (!(hdev->clock_gating_mask &
- (BIT_ULL(gaudi_dma_assignment[i]
- continue;
+ enable = !!(hdev->clock_gating_mask &
+ (BIT_ULL(gaudi_dma_assignment[i])));
qman_offset = gaudi_dma_assignment[i] * DMA_QMAN_OFFSET;
- WREG32(mmDMA0_QM_CGM_CFG1 + qman_offset, QMAN_CGM1_PWR_GATE_EN);
+ WREG32(mmDMA0_QM_CGM_CFG1 + qman_offset,
+ enable ? QMAN_CGM1_PWR_GATE_EN : 0);
WREG32(mmDMA0_QM_CGM_CFG + qman_offset,
- QMAN_COMMON_CP_CGM_PWR_GATE_EN);
+ enable ? QMAN_COMMON_CP_CGM_PWR_GATE_EN : 0);
}
- if (hdev->clock_gating_mask & (BIT_ULL(GAUDI_ENGINE_ID_MME_0))) {
- WREG32(mmMME0_QM_CGM_CFG1, QMAN_CGM1_PWR_GATE_EN);
- WREG32(mmMME0_QM_CGM_CFG, QMAN_COMMON_CP_CGM_PWR_GATE_EN);
- }
+ enable = !!(hdev->clock_gating_mask & (BIT_ULL(GAUDI_ENGINE_ID_MME_0)));
+ WREG32(mmMME0_QM_CGM_CFG1, enable ? QMAN_CGM1_PWR_GATE_EN : 0);
+ WREG32(mmMME0_QM_CGM_CFG, enable ? QMAN_COMMON_CP_CGM_PWR_GATE_EN : 0);
- if (hdev->clock_gating_mask & (BIT_ULL(GAUDI_ENGINE_ID_MME_2))) {
- WREG32(mmMME2_QM_CGM_CFG1, QMAN_CGM1_PWR_GATE_EN);
- WREG32(mmMME2_QM_CGM_CFG, QMAN_COMMON_CP_CGM_PWR_GATE_EN);
- }
+ enable = !!(hdev->clock_gating_mask & (BIT_ULL(GAUDI_ENGINE_ID_MME_2)));
+ WREG32(mmMME2_QM_CGM_CFG1, enable ? QMAN_CGM1_PWR_GATE_EN : 0);
+ WREG32(mmMME2_QM_CGM_CFG, enable ? QMAN_COMMON_CP_CGM_PWR_GATE_EN : 0);
for (i = 0, qman_offset = 0 ; i < TPC_NUMBER_OF_ENGINES ; i++) {
- if (!(hdev->clock_gating_mask &
- (BIT_ULL(GAUDI_ENGINE_ID_TPC_0 + i
- continue;
+ enable = !!(hdev->clock_gating_mask &
+ (BIT_ULL(GAUDI_ENGINE_ID_TPC_0 + i)));
WREG32(mmTPC0_QM_CGM_CFG1 + qman_offset,
- QMAN_CGM1_PWR_GATE_EN);
+ enable ? QMAN_CGM1_PWR_GATE_EN : 0);
WREG32(mmTPC0_QM_CGM_CFG + qman_offset,
- QMAN_COMMON_CP_CGM_PWR_GATE_EN);
+ enable ? QMAN_COMMON_CP_CGM_PWR_GATE_EN : 0);
qman_offset += TPC_QMAN_OFFSET;
}
--
2.17.1
[PATCH 1/4] habanalabs: verify user input in cs_ioctl_signal_wait
From: Ofir Bitton
User input must be validated before using it to
access internal structures.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/common/command_submission.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/misc/habanalabs/common/command_submission.c
b/drivers/misc/habanalabs/common/command_submission.c
index b9840e368eb5..2e3fcbc794db 100644
--- a/drivers/misc/habanalabs/common/command_submission.c
+++ b/drivers/misc/habanalabs/common/command_submission.c
@@ -808,6 +808,14 @@ static int cs_ioctl_signal_wait(struct hl_fpriv *hpriv,
enum hl_cs_type cs_type,
/* currently it is guaranteed to have only one chunk */
chunk = _chunk_array[0];
+
+ if (chunk->queue_index >= hdev->asic_prop.max_queues) {
+ dev_err(hdev->dev, "Queue index %d is invalid\n",
+ chunk->queue_index);
+ rc = -EINVAL;
+ goto free_cs_chunk_array;
+ }
+
q_idx = chunk->queue_index;
hw_queue_prop = >asic_prop.hw_queues_props[q_idx];
q_type = hw_queue_prop->type;
--
2.17.1
[PATCH 4/4] habanalabs: set max power according to card type
In Gaudi, the default max power setting is different between PCI and PMC
cards. Therefore, the driver need to set the default after knowing what is
the card type.
The current code has a bug where it limits the maximum power of the PMC
card to 200W after a reset occurs.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/common/device.c | 7 ++-
drivers/misc/habanalabs/common/habanalabs.h | 2 +-
drivers/misc/habanalabs/common/sysfs.c | 7 ---
drivers/misc/habanalabs/gaudi/gaudi.c | 9 -
drivers/misc/habanalabs/gaudi/gaudiP.h | 3 ++-
5 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/habanalabs/common/device.c
b/drivers/misc/habanalabs/common/device.c
index be16b75bdfdb..8e34c39380a9 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -1069,7 +1069,7 @@ int hl_device_reset(struct hl_device *hdev, bool
hard_reset,
goto out_err;
}
- hl_set_max_power(hdev, hdev->max_power);
+ hl_set_max_power(hdev);
} else {
rc = hdev->asic_funcs->soft_reset_late_init(hdev);
if (rc) {
@@ -1318,6 +1318,11 @@ int hl_device_init(struct hl_device *hdev, struct class
*hclass)
goto out_disabled;
}
+ /* Need to call this again because the max power might change,
+* depending on card type for certain ASICs
+*/
+ hl_set_max_power(hdev);
+
/*
* hl_hwmon_init() must be called after device_late_init(), because only
* there we get the information from the device about which
diff --git a/drivers/misc/habanalabs/common/habanalabs.h
b/drivers/misc/habanalabs/common/habanalabs.h
index 13c18f3d9a9b..5864c6adfc52 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -1858,7 +1858,7 @@ int hl_get_pwm_info(struct hl_device *hdev,
void hl_set_pwm_info(struct hl_device *hdev, int sensor_index, u32 attr,
long value);
u64 hl_get_max_power(struct hl_device *hdev);
-void hl_set_max_power(struct hl_device *hdev, u64 value);
+void hl_set_max_power(struct hl_device *hdev);
int hl_set_voltage(struct hl_device *hdev,
int sensor_index, u32 attr, long value);
int hl_set_current(struct hl_device *hdev,
diff --git a/drivers/misc/habanalabs/common/sysfs.c
b/drivers/misc/habanalabs/common/sysfs.c
index b3cb0ac4721c..5ae484cc84cd 100644
--- a/drivers/misc/habanalabs/common/sysfs.c
+++ b/drivers/misc/habanalabs/common/sysfs.c
@@ -81,7 +81,7 @@ u64 hl_get_max_power(struct hl_device *hdev)
return result;
}
-void hl_set_max_power(struct hl_device *hdev, u64 value)
+void hl_set_max_power(struct hl_device *hdev)
{
struct armcp_packet pkt;
int rc;
@@ -90,7 +90,7 @@ void hl_set_max_power(struct hl_device *hdev, u64 value)
pkt.ctl = cpu_to_le32(ARMCP_PACKET_MAX_POWER_SET <<
ARMCP_PKT_CTL_OPCODE_SHIFT);
- pkt.value = cpu_to_le64(value);
+ pkt.value = cpu_to_le64(hdev->max_power);
rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) , sizeof(pkt),
0, NULL);
@@ -316,7 +316,7 @@ static ssize_t max_power_store(struct device *dev,
}
hdev->max_power = value;
- hl_set_max_power(hdev, value);
+ hl_set_max_power(hdev);
out:
return count;
@@ -422,6 +422,7 @@ int hl_sysfs_init(struct hl_device *hdev)
hdev->pm_mng_profile = PM_AUTO;
else
hdev->pm_mng_profile = PM_MANUAL;
+
hdev->max_power = hdev->asic_prop.max_power_default;
hdev->asic_funcs->add_device_attr(hdev, _dev_clks_attr_group);
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 7e0f9f64ffcb..c58343608cc7 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -456,7 +456,7 @@ static int gaudi_get_fixed_properties(struct hl_device
*hdev)
prop->num_of_events = GAUDI_EVENT_SIZE;
prop->tpc_enabled_mask = TPC_ENABLED_MASK;
- prop->max_power_default = MAX_POWER_DEFAULT;
+ prop->max_power_default = MAX_POWER_DEFAULT_PMC;
prop->cb_pool_cb_cnt = GAUDI_CB_POOL_CB_CNT;
prop->cb_pool_cb_size = GAUDI_CB_POOL_CB_SIZE;
@@ -6055,6 +6055,13 @@ static int gaudi_armcp_info_get(struct hl_device *hdev)
strncpy(prop->armcp_info.card_name, GAUDI_DEFAULT_CARD_NAME,
CARD_NAME_MAX_LEN);
+ if (prop->armcp_info.card_type == armcp_card_type_pci)
+ prop->max_power_default = MAX_POWER_DEFAULT_PCI;
+ else if (prop->armcp_info.card_type == armcp_card_type_pmc)
+ prop->max_power_default = MAX_POWER_DEFAULT_PMC;
+
+ hdev->max_power = prop->max_power_default;
+
return 0;
}
[PATCH 3/4] habanalabs: proper handling of alloc size in coresight
From: Ofir Bitton
Allocation size can go up to 64bit but truncated to 32bit,
we should make sure it is not truncated and validate no address
overflow.
Signed-off-by: Ofir Bitton
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/common/habanalabs.h | 2 +-
drivers/misc/habanalabs/gaudi/gaudi_coresight.c | 8 +++-
drivers/misc/habanalabs/goya/goya_coresight.c | 8 +++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/habanalabs/common/habanalabs.h
b/drivers/misc/habanalabs/common/habanalabs.h
index 018d9d67e8e6..13c18f3d9a9b 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -1651,7 +1651,7 @@ struct hl_ioctl_desc {
*
* Return: true if the area is inside the valid range, false otherwise.
*/
-static inline bool hl_mem_area_inside_range(u64 address, u32 size,
+static inline bool hl_mem_area_inside_range(u64 address, u64 size,
u64 range_start_address, u64 range_end_address)
{
u64 end_address = address + size;
diff --git a/drivers/misc/habanalabs/gaudi/gaudi_coresight.c
b/drivers/misc/habanalabs/gaudi/gaudi_coresight.c
index 5673ee49819e..881531d4d9da 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi_coresight.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi_coresight.c
@@ -527,7 +527,7 @@ static int gaudi_config_etf(struct hl_device *hdev,
}
static bool gaudi_etr_validate_address(struct hl_device *hdev, u64 addr,
- u32 size, bool *is_host)
+ u64 size, bool *is_host)
{
struct asic_fixed_properties *prop = >asic_prop;
struct gaudi_device *gaudi = hdev->asic_specific;
@@ -539,6 +539,12 @@ static bool gaudi_etr_validate_address(struct hl_device
*hdev, u64 addr,
return false;
}
+ if (addr > (addr + size)) {
+ dev_err(hdev->dev,
+ "ETR buffer size %llu overflow\n", size);
+ return false;
+ }
+
/* PMMU and HPMMU addresses are equal, check only one of them */
if ((gaudi->hw_cap_initialized & HW_CAP_MMU) &&
hl_mem_area_inside_range(addr, size,
diff --git a/drivers/misc/habanalabs/goya/goya_coresight.c
b/drivers/misc/habanalabs/goya/goya_coresight.c
index b03912483de0..4027a6a334d7 100644
--- a/drivers/misc/habanalabs/goya/goya_coresight.c
+++ b/drivers/misc/habanalabs/goya/goya_coresight.c
@@ -362,11 +362,17 @@ static int goya_config_etf(struct hl_device *hdev,
}
static int goya_etr_validate_address(struct hl_device *hdev, u64 addr,
- u32 size)
+ u64 size)
{
struct asic_fixed_properties *prop = >asic_prop;
u64 range_start, range_end;
+ if (addr > (addr + size)) {
+ dev_err(hdev->dev,
+ "ETR buffer size %llu overflow\n", size);
+ return false;
+ }
+
if (hdev->mmu_enable) {
range_start = prop->dmmu.start_addr;
range_end = prop->dmmu.end_addr;
--
2.17.1
Re: [PATCH v6 2/4] SFH: PCIe driver to add support of AMD sensor fusion
Hi Sandeep,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8 next-20200807]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sandeep-Singh/SFH-Add-Support-for-AMD-Sensor-Fusion-Hub/20200809-182729
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/hid/amd-sfh-hid/amd_mp2_pcie.c: In function 'amd_mp2_pci_init':
>> drivers/hid/amd-sfh-hid/amd_mp2_pcie.c:107:2: warning: ignoring return value
>> of 'pcim_enable_device', declared with attribute warn_unused_result
>> [-Wunused-result]
107 | pcim_enable_device(pdev);
| ^~~~
vim +/pcim_enable_device +107 drivers/hid/amd-sfh-hid/amd_mp2_pcie.c
101
102 static int amd_mp2_pci_init(struct amd_mp2_dev *privdata, struct
pci_dev *pdev)
103 {
104 int rc;
105
106 pci_set_drvdata(pdev, privdata);
> 107 pcim_enable_device(pdev);
108 pcim_iomap_regions(pdev, BIT(2), DRIVER_NAME);
109
110 privdata->mmio = pcim_iomap_table(pdev)[2];
111 pci_set_master(pdev);
112
113 rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
114 if (rc)
115 rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
116 return rc;
117 }
118
---
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] drivers: bluetooth: btintel.c: fixed format issue.
Hi YourName,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bluetooth-next/master]
[also build test WARNING on v5.8 next-20200807]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/YourName/drivers-bluetooth-btintel-c-fixed-format-issue/20200809-152614
base:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
master
config: i386-randconfig-m021-20200809 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/bluetooth/btintel.c:32 btintel_check_bdaddr() warn: inconsistent
indenting
vim +32 drivers/bluetooth/btintel.c
48f0ed1bb68589 Marcel Holtmann 2015-04-06 22
48f0ed1bb68589 Marcel Holtmann 2015-04-06 23 int btintel_check_bdaddr(struct
hci_dev *hdev)
48f0ed1bb68589 Marcel Holtmann 2015-04-06 24 {
48f0ed1bb68589 Marcel Holtmann 2015-04-06 25 struct hci_rp_read_bd_addr *bda;
48f0ed1bb68589 Marcel Holtmann 2015-04-06 26 struct sk_buff *skb;
48f0ed1bb68589 Marcel Holtmann 2015-04-06 27
48f0ed1bb68589 Marcel Holtmann 2015-04-06 28 skb = __hci_cmd_sync(hdev,
HCI_OP_READ_BD_ADDR, 0, NULL,
48f0ed1bb68589 Marcel Holtmann 2015-04-06 29
HCI_INIT_TIMEOUT);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 30 if (IS_ERR(skb)) {
48f0ed1bb68589 Marcel Holtmann 2015-04-06 31 int err = PTR_ERR(skb);
2064ee332e4c1b Marcel Holtmann 2017-10-30 @32
bt_dev_err(hdev, "Reading Intel device address failed (%d)",
2064ee332e4c1b Marcel Holtmann 2017-10-30 33 err);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 34 return err;
48f0ed1bb68589 Marcel Holtmann 2015-04-06 35 }
48f0ed1bb68589 Marcel Holtmann 2015-04-06 36
48f0ed1bb68589 Marcel Holtmann 2015-04-06 37 if (skb->len != sizeof(*bda)) {
2064ee332e4c1b Marcel Holtmann 2017-10-30 38 bt_dev_err(hdev, "Intel
device address length mismatch");
48f0ed1bb68589 Marcel Holtmann 2015-04-06 39 kfree_skb(skb);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 40 return -EIO;
48f0ed1bb68589 Marcel Holtmann 2015-04-06 41 }
48f0ed1bb68589 Marcel Holtmann 2015-04-06 42
48f0ed1bb68589 Marcel Holtmann 2015-04-06 43 bda = (struct
hci_rp_read_bd_addr *)skb->data;
48f0ed1bb68589 Marcel Holtmann 2015-04-06 44
48f0ed1bb68589 Marcel Holtmann 2015-04-06 45 /* For some Intel based
controllers, the default Bluetooth device
48f0ed1bb68589 Marcel Holtmann 2015-04-06 46* address 00:03:19:9E:8B:00
can be found. These controllers are
48f0ed1bb68589 Marcel Holtmann 2015-04-06 47* fully operational, but have
the danger of duplicate addresses
48f0ed1bb68589 Marcel Holtmann 2015-04-06 48* and that in turn can cause
problems with Bluetooth operation.
48f0ed1bb68589 Marcel Holtmann 2015-04-06 49*/
48f0ed1bb68589 Marcel Holtmann 2015-04-06 50 if (!bacmp(>bdaddr,
BDADDR_INTEL)) {
2064ee332e4c1b Marcel Holtmann 2017-10-30 51 bt_dev_err(hdev, "Found
Intel default device address (%pMR)",
2064ee332e4c1b Marcel Holtmann 2017-10-30 52
>bdaddr);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 53
set_bit(HCI_QUIRK_INVALID_BDADDR, >quirks);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 54 }
48f0ed1bb68589 Marcel Holtmann 2015-04-06 55
48f0ed1bb68589 Marcel Holtmann 2015-04-06 56 kfree_skb(skb);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 57
48f0ed1bb68589 Marcel Holtmann 2015-04-06 58 return 0;
48f0ed1bb68589 Marcel Holtmann 2015-04-06 59 }
48f0ed1bb68589 Marcel Holtmann 2015-04-06 60
EXPORT_SYMBOL_GPL(btintel_check_bdaddr);
48f0ed1bb68589 Marcel Holtmann 2015-04-06 61
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] habanalabs: print the queue id in case of an error
From: Dotan Barak
If there is a failure during the testing of a queue,
to ease up debugging - print the queue id.
Signed-off-by: Dotan Barak
Reviewed-by: Oded Gabbay
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/gaudi/gaudi.c | 9 ++---
drivers/misc/habanalabs/goya/goya.c | 9 ++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 437219985327..6febfe4fdd81 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -3427,7 +3427,8 @@ static int gaudi_test_queue(struct hl_device *hdev, u32
hw_queue_id)
_dma_addr);
if (!fence_ptr) {
dev_err(hdev->dev,
- "Failed to allocate memory for queue testing\n");
+ "Failed to allocate memory for H/W queue %d testing\n",
+ hw_queue_id);
return -ENOMEM;
}
@@ -3438,7 +3439,8 @@ static int gaudi_test_queue(struct hl_device *hdev, u32
hw_queue_id)
GFP_KERNEL, _dma_addr);
if (!fence_pkt) {
dev_err(hdev->dev,
- "Failed to allocate packet for queue testing\n");
+ "Failed to allocate packet for H/W queue %d testing\n",
+ hw_queue_id);
rc = -ENOMEM;
goto free_fence_ptr;
}
@@ -3455,7 +3457,8 @@ static int gaudi_test_queue(struct hl_device *hdev, u32
hw_queue_id)
pkt_dma_addr);
if (rc) {
dev_err(hdev->dev,
- "Failed to send fence packet\n");
+ "Failed to send fence packet to H/W queue %d\n",
+ hw_queue_id);
goto free_pkt;
}
diff --git a/drivers/misc/habanalabs/goya/goya.c
b/drivers/misc/habanalabs/goya/goya.c
index c497ae25c331..77a5963a4d10 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -2927,7 +2927,8 @@ int goya_test_queue(struct hl_device *hdev, u32
hw_queue_id)
_dma_addr);
if (!fence_ptr) {
dev_err(hdev->dev,
- "Failed to allocate memory for queue testing\n");
+ "Failed to allocate memory for H/W queue %d testing\n",
+ hw_queue_id);
return -ENOMEM;
}
@@ -2938,7 +2939,8 @@ int goya_test_queue(struct hl_device *hdev, u32
hw_queue_id)
GFP_KERNEL, _dma_addr);
if (!fence_pkt) {
dev_err(hdev->dev,
- "Failed to allocate packet for queue testing\n");
+ "Failed to allocate packet for H/W queue %d testing\n",
+ hw_queue_id);
rc = -ENOMEM;
goto free_fence_ptr;
}
@@ -2955,7 +2957,8 @@ int goya_test_queue(struct hl_device *hdev, u32
hw_queue_id)
pkt_dma_addr);
if (rc) {
dev_err(hdev->dev,
- "Failed to send fence packet\n");
+ "Failed to send fence packet to H/W queue %d\n",
+ hw_queue_id);
goto free_pkt;
}
--
2.17.1
Re: [PATCH][next] habanalabs: fix incorrect check on failed workqueue create
On Sun, Aug 09, 2020 at 02:02:18PM +0300, Oded Gabbay wrote:
> On Fri, Jul 31, 2020 at 9:21 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jul 30, 2020 at 01:51:48PM +0300, Oded Gabbay wrote:
> > > On Thu, Jul 30, 2020 at 11:20 AM Colin King
> > > wrote:
> > > >
> > > > From: Colin Ian King
> > > >
> > > > The null check on a failed workqueue create is currently null checking
> > > > hdev->cq_wq rather than the pointer hdev->cq_wq[i] and so the test
> > > > will never be true on a failed workqueue create. Fix this by checking
> > > > hdev->cq_wq[i].
> > > >
> > > > Addresses-Coverity: ("Dereference before null check")
> > > > Fixes: 5574cb2194b1 ("habanalabs: Assign each CQ with its own work
> > > > queue")
> > > > Signed-off-by: Colin Ian King
> > > > ---
> > > > drivers/misc/habanalabs/common/device.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/misc/habanalabs/common/device.c
> > > > b/drivers/misc/habanalabs/common/device.c
> > > > index be16b75bdfdb..35214a186913 100644
> > > > --- a/drivers/misc/habanalabs/common/device.c
> > > > +++ b/drivers/misc/habanalabs/common/device.c
> > > > @@ -288,7 +288,7 @@ static int device_early_init(struct hl_device *hdev)
> > > > for (i = 0 ; i < hdev->asic_prop.completion_queues_count ; i++)
> > > > {
> > > > snprintf(workq_name, 32, "hl-free-jobs-%u", i);
> > > > hdev->cq_wq[i] =
> > > > create_singlethread_workqueue(workq_name);
> > > > - if (hdev->cq_wq == NULL) {
> > > > + if (hdev->cq_wq[i] == NULL) {
> > > > dev_err(hdev->dev, "Failed to allocate CQ
> > > > workqueue\n");
> > > > rc = -ENOMEM;
> > > > goto free_cq_wq;
> > > > --
> > > > 2.27.0
> > > >
> > >
> > > This patch is:
> > > Reviewed-by: Oded Gabbay
> > >
> > > Greg, can you please apply it directly to the char-misc-next branch ?
> > > I don't want to send a pull request for 1 patch.
> >
> > Already merged :)
>
> Hi Greg,
> I can't find this patch in char-misc-next.
> Can you please check if you applied it ?
Oops, you are right, I did not take it, my fault, sorry.
> If not, I'll apply it to my fixes tree and send it to you for -rc2
That would be great, thanks for following up on this.
greg k-h
Re: [PATCH][next] habanalabs: fix incorrect check on failed workqueue create
On Sun, Aug 9, 2020 at 3:02 PM Greg Kroah-Hartman
wrote:
>
> On Sun, Aug 09, 2020 at 02:02:18PM +0300, Oded Gabbay wrote:
> > On Fri, Jul 31, 2020 at 9:21 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Thu, Jul 30, 2020 at 01:51:48PM +0300, Oded Gabbay wrote:
> > > > On Thu, Jul 30, 2020 at 11:20 AM Colin King
> > > > wrote:
> > > > >
> > > > > From: Colin Ian King
> > > > >
> > > > > The null check on a failed workqueue create is currently null checking
> > > > > hdev->cq_wq rather than the pointer hdev->cq_wq[i] and so the test
> > > > > will never be true on a failed workqueue create. Fix this by checking
> > > > > hdev->cq_wq[i].
> > > > >
> > > > > Addresses-Coverity: ("Dereference before null check")
> > > > > Fixes: 5574cb2194b1 ("habanalabs: Assign each CQ with its own work
> > > > > queue")
> > > > > Signed-off-by: Colin Ian King
> > > > > ---
> > > > > drivers/misc/habanalabs/common/device.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/misc/habanalabs/common/device.c
> > > > > b/drivers/misc/habanalabs/common/device.c
> > > > > index be16b75bdfdb..35214a186913 100644
> > > > > --- a/drivers/misc/habanalabs/common/device.c
> > > > > +++ b/drivers/misc/habanalabs/common/device.c
> > > > > @@ -288,7 +288,7 @@ static int device_early_init(struct hl_device
> > > > > *hdev)
> > > > > for (i = 0 ; i < hdev->asic_prop.completion_queues_count ;
> > > > > i++) {
> > > > > snprintf(workq_name, 32, "hl-free-jobs-%u", i);
> > > > > hdev->cq_wq[i] =
> > > > > create_singlethread_workqueue(workq_name);
> > > > > - if (hdev->cq_wq == NULL) {
> > > > > + if (hdev->cq_wq[i] == NULL) {
> > > > > dev_err(hdev->dev, "Failed to allocate CQ
> > > > > workqueue\n");
> > > > > rc = -ENOMEM;
> > > > > goto free_cq_wq;
> > > > > --
> > > > > 2.27.0
> > > > >
> > > >
> > > > This patch is:
> > > > Reviewed-by: Oded Gabbay
> > > >
> > > > Greg, can you please apply it directly to the char-misc-next branch ?
> > > > I don't want to send a pull request for 1 patch.
> > >
> > > Already merged :)
> >
> > Hi Greg,
> > I can't find this patch in char-misc-next.
> > Can you please check if you applied it ?
>
> Oops, you are right, I did not take it, my fault, sorry.
>
> > If not, I'll apply it to my fixes tree and send it to you for -rc2
>
> That would be great, thanks for following up on this.
>
> greg k-h
Sure, np.
Thanks,
Oded
Re: [PATCH] gpu/drm: Remove TTM_PL_FLAG_WC of VRAM to fix writecombine issue for Loongson64
Am 08.08.20 um 15:50 schrieb Jiaxun Yang:
在 2020/8/8 下午9:41, Thomas Bogendoerfer 写道:
On Sat, Aug 08, 2020 at 03:25:02PM +0800, Tiezhu Yang wrote:
Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times,
after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
mapping for MIPS"), there exists some errors such as blurred screen
and lockup, and so on.
Remove the flag TTM_PL_FLAG_WC of VRAM to fix writecombine issue for
Loongson64 to work well with ATI Radeon or AMD GPU, and it has no any
influence on the other platforms.
well it's not my call to take or reject this patch, but I already
indicated it might be better to disable writecombine on the CPU
detection side (or do you have other devices where writecombining
works ?). Something like below will disbale it for all loongson64 CPUs.
If you now find out where it works and where it doesn't, you can even
reduce it to the required minium of affected CPUs.
Hi Tiezhu, Thomas,
Yes, writecombine works well on LS7A's internal GPU
And even works well with some AMD GPUs (in my case, RX550).
In this case the patch is a clear NAK since you haven't root caused the
issue and are just working around it in a very questionable manner.
Tiezhu, is it possible to investigate the issue deeper in Loongson?
Probably we just need to add some barrier to maintain the data coherency,
or disable writecombine for AMD GPU's command buffer and leave
texture/frame
buffer wc accelerated.
Have you moved any buffer to VRAM and forgot to add an HDP flush/invalidate?
The acceleration is not much of a problem, but if WC doesn't work in
general you need to disable it for the whole CPU and not for individual
drivers.
Regards,
Christian.
Thanks.
- Jiaxun
fs/f2fs/file.c:761:9: warning: Identical condition 'err', second condition is always false
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 06a81c1c7db9bd5de0bd38cd5acc44bb22b99150 commit: 3265d3db1f16395cfc6b8ea9b31b4001d98d05ef f2fs: support partial truncation on compressed inode date: 3 months ago compiler: xtensa-linux-gcc (GCC) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot cppcheck warnings: (new ones prefixed by >>) >> fs/f2fs/file.c:761:9: warning: Identical condition 'err', second condition >> is always false [identicalConditionAfterEarlyExit] return err; ^ fs/f2fs/file.c:753:6: note: first condition if (err) ^ fs/f2fs/file.c:761:9: note: second condition return err; ^ >> fs/f2fs/file.c:1689:12: warning: Variable 'new_size' is reassigned a value >> before the old one has been used. [redundantAssignment] new_size = (last_off == pg_end) ? offset + len : ^ fs/f2fs/file.c:1620:0: note: Variable 'new_size' is reassigned a value before the old one has been used. loff_t new_size = i_size_read(inode); ^ fs/f2fs/file.c:1689:12: note: Variable 'new_size' is reassigned a value before the old one has been used. new_size = (last_off == pg_end) ? offset + len : ^ >> fs/f2fs/file.c:2789:6: warning: Variable 'ret' is reassigned a value before >> the old one has been used. [redundantAssignment] ret = -EINVAL; ^ fs/f2fs/file.c:2784:7: note: Variable 'ret' is reassigned a value before the old one has been used. ret = -EBUSY; ^ fs/f2fs/file.c:2789:6: note: Variable 'ret' is reassigned a value before the old one has been used. ret = -EINVAL; ^ fs/f2fs/file.c:2811:6: warning: Variable 'ret' is reassigned a value before the old one has been used. [redundantAssignment] ret = f2fs_convert_inline_inode(src); ^ fs/f2fs/file.c:2789:6: note: Variable 'ret' is reassigned a value before the old one has been used. ret = -EINVAL; ^ fs/f2fs/file.c:2811:6: note: Variable 'ret' is reassigned a value before the old one has been used. ret = f2fs_convert_inline_inode(src); ^ fs/f2fs/file.c:2840:6: warning: Variable 'ret' is reassigned a value before the old one has been used. [redundantAssignment] ret = __exchange_data_block(src, dst, pos_in >> F2FS_BLKSIZE_BITS, ^ fs/f2fs/file.c:2834:7: note: Variable 'ret' is reassigned a value before the old one has been used. ret = -EBUSY; ^ fs/f2fs/file.c:2840:6: note: Variable 'ret' is reassigned a value before the old one has been used. ret = __exchange_data_block(src, dst, pos_in >> F2FS_BLKSIZE_BITS, ^ fs/f2fs/f2fs.h:2209:15: warning: Local variable valid_node_count shadows outer function [shadowFunction] unsigned int valid_node_count, user_block_count; ^ fs/f2fs/f2fs.h:2305:28: note: Shadowed declaration static inline unsigned int valid_node_count(struct f2fs_sb_info *sbi) ^ fs/f2fs/f2fs.h:2209:15: note: Shadow variable unsigned int valid_node_count, user_block_count; ^ vim +/err +761 fs/f2fs/file.c 760 > 761 return err; 762 } 763 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH 2/9] ufs: ufs-qcom: Fix race conditions caused by func ufs_qcom_testbus_config
If ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from ufshcd_suspend/resume and/or clk gate/ungate context, pm_runtime_get_sync() and ufshcd_hold() will cause racing problems. Fix this by removing the unnecessary calls of pm_runtime_get_sync() and ufshcd_hold(). Signed-off-by: Can Guo Reviewed-by: Hongwu Su Reviewed-by: Avri Altman Reviewed-by: Bean Huo Reviewed-by: Asutosh Das diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c index d0d7552..823eccf 100644 --- a/drivers/scsi/ufs/ufs-qcom.c +++ b/drivers/scsi/ufs/ufs-qcom.c @@ -1614,9 +1614,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host) */ } mask <<= offset; - - pm_runtime_get_sync(host->hba->dev); - ufshcd_hold(host->hba, false); ufshcd_rmwl(host->hba, TEST_BUS_SEL, (u32)host->testbus.select_major << 19, REG_UFS_CFG1); @@ -1629,8 +1626,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host) * committed before returning. */ mb(); - ufshcd_release(host->hba); - pm_runtime_put_sync(host->hba->dev); return 0; } -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 6/9] scsi: ufs: Recover hba runtime PM error in error handler
Current error handler cannot work well or recover hba runtime PM error if
ufshcd_suspend/resume has failed due to UFS errors, e.g. hibern8 enter/exit
error or SSU cmd error. When this happens, error handler may fail doing
full reset and restore because error handler always assumes that powers,
IRQs and clocks are ready after pm_runtime_get_sync returns, but actually
they are not if ufshcd_reusme fails [1]. Besides, if ufschd_suspend/resume
fails due to UFS error, runtime PM framework saves the error value to
dev.power.runtime_error. After that, hba dev runtime suspend/resume would
not be invoked anymore unless runtime_error is cleared [2].
In case of ufshcd_suspend/resume fails due to UFS errors, for scenario [1],
error handler cannot assume anything of pm_runtime_get_sync, meaning error
handler should explicitly turn ON powers, IRQs and clocks again. To get the
hba runtime PM work as regard for scenario [2], error handler can clear the
runtime_error by calling pm_runtime_set_active() if full reset and restore
succeeds. And, more important, if pm_runtime_set_active() returns no error,
which means runtime_error has been cleared, we also need to resume those
scsi devices under hba in case any of them has failed to be resumed due to
hba runtime resume failure. This is to unblock blk_queue_enter in case
there are bios waiting inside it.
Signed-off-by: Can Guo
Reviewed-by: Bean Huo
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2604016..ed24582 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "ufshcd.h"
#include "ufs_quirks.h"
#include "unipro.h"
@@ -229,6 +230,10 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba);
static int ufshcd_change_power_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *pwr_mode);
static void ufshcd_schedule_eh_work(struct ufs_hba *hba);
+static int ufshcd_setup_hba_vreg(struct ufs_hba *hba, bool on);
+static int ufshcd_setup_vreg(struct ufs_hba *hba, bool on);
+static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
+struct ufs_vreg *vreg);
static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
@@ -5553,6 +5558,84 @@ static inline void ufshcd_schedule_eh_work(struct
ufs_hba *hba)
}
}
+static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
+{
+ pm_runtime_get_sync(hba->dev);
+ if (pm_runtime_suspended(hba->dev)) {
+ /*
+* Don't assume anything of pm_runtime_get_sync(), if
+* resume fails, irq and clocks can be OFF, and powers
+* can be OFF or in LPM.
+*/
+ ufshcd_setup_hba_vreg(hba, true);
+ ufshcd_enable_irq(hba);
+ ufshcd_setup_vreg(hba, true);
+ ufshcd_config_vreg_hpm(hba, hba->vreg_info.vccq);
+ ufshcd_config_vreg_hpm(hba, hba->vreg_info.vccq2);
+ ufshcd_hold(hba, false);
+ if (!ufshcd_is_clkgating_allowed(hba))
+ ufshcd_setup_clocks(hba, true);
+ ufshcd_release(hba);
+ ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
+ } else {
+ ufshcd_hold(hba, false);
+ if (hba->clk_scaling.is_allowed) {
+ cancel_work_sync(>clk_scaling.suspend_work);
+ cancel_work_sync(>clk_scaling.resume_work);
+ ufshcd_suspend_clkscaling(hba);
+ }
+ }
+}
+
+static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
+{
+ ufshcd_release(hba);
+ if (hba->clk_scaling.is_allowed)
+ ufshcd_resume_clkscaling(hba);
+ pm_runtime_put(hba->dev);
+}
+
+static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)
+{
+ return (hba->ufshcd_state == UFSHCD_STATE_ERROR ||
+ (!(hba->saved_err || hba->saved_uic_err || hba->force_reset ||
+ ufshcd_is_link_broken(hba;
+}
+
+#ifdef CONFIG_PM
+static void ufshcd_recover_pm_error(struct ufs_hba *hba)
+{
+ struct Scsi_Host *shost = hba->host;
+ struct scsi_device *sdev;
+ struct request_queue *q;
+ int ret;
+
+ /*
+* Set RPM status of hba device to RPM_ACTIVE,
+* this also clears its runtime error.
+*/
+ ret = pm_runtime_set_active(hba->dev);
+ /*
+* If hba device had runtime error, we also need to resume those
+* scsi devices under hba in case any of them has failed to be
+* resumed due to hba runtime resume failure. This is to unblock
+* blk_queue_enter in case there are bios waiting inside it.
+*/
+ if (!ret) {
+ shost_for_each_device(sdev,
[PATCH 3/9] scsi: ufs-qcom: Remove testbus dump in ufs_qcom_dump_dbg_regs
Dumping testbus registers is heavy enough to cause stability issues
sometime, just remove them as of now.
Signed-off-by: Can Guo
Reviewed-by: Hongwu Su
Reviewed-by: Avri Altman
Reviewed-by: Bean Huo
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 823eccf..6b75338 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1630,44 +1630,12 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
return 0;
}
-static void ufs_qcom_testbus_read(struct ufs_hba *hba)
-{
- ufshcd_dump_regs(hba, UFS_TEST_BUS, 4, "UFS_TEST_BUS ");
-}
-
-static void ufs_qcom_print_unipro_testbus(struct ufs_hba *hba)
-{
- struct ufs_qcom_host *host = ufshcd_get_variant(hba);
- u32 *testbus = NULL;
- int i, nminor = 256, testbus_len = nminor * sizeof(u32);
-
- testbus = kmalloc(testbus_len, GFP_KERNEL);
- if (!testbus)
- return;
-
- host->testbus.select_major = TSTBUS_UNIPRO;
- for (i = 0; i < nminor; i++) {
- host->testbus.select_minor = i;
- ufs_qcom_testbus_config(host);
- testbus[i] = ufshcd_readl(hba, UFS_TEST_BUS);
- }
- print_hex_dump(KERN_ERR, "UNIPRO_TEST_BUS ", DUMP_PREFIX_OFFSET,
- 16, 4, testbus, testbus_len, false);
- kfree(testbus);
-}
-
static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
{
ufshcd_dump_regs(hba, REG_UFS_SYS1CLK_1US, 16 * 4,
"HCI Vendor Specific Registers ");
- /* sleep a bit intermittently as we are dumping too much data */
ufs_qcom_print_hw_debug_reg_all(hba, NULL, ufs_qcom_dump_regs_wrapper);
- udelay(1000);
- ufs_qcom_testbus_read(hba);
- udelay(1000);
- ufs_qcom_print_unipro_testbus(hba);
- udelay(1000);
}
/**
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH 1/9] scsi: ufs: Add checks before setting clk-gating states
Clock gating features can be turned on/off selectively which means its
state information is only important if it is enabled. This change makes
sure that we only look at state of clk-gating if it is enabled.
Signed-off-by: Can Guo
Reviewed-by: Avri Altman
Reviewed-by: Hongwu Su
Reviewed-by: Stanley Chu
Reviewed-by: Bean Huo
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 3076222..5acb38c 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1839,6 +1839,8 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
if (!ufshcd_is_clkgating_allowed(hba))
return;
+ hba->clk_gating.state = CLKS_ON;
+
hba->clk_gating.delay_ms = 150;
INIT_DELAYED_WORK(>clk_gating.gate_work, ufshcd_gate_work);
INIT_WORK(>clk_gating.ungate_work, ufshcd_ungate_work);
@@ -2541,7 +2543,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
err = SCSI_MLQUEUE_HOST_BUSY;
goto out;
}
- WARN_ON(hba->clk_gating.state != CLKS_ON);
+ WARN_ON(ufshcd_is_clkgating_allowed(hba) &&
+ (hba->clk_gating.state != CLKS_ON));
lrbp = >lrb[tag];
@@ -8326,8 +8329,11 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum
ufs_pm_op pm_op)
/* If link is active, device ref_clk can't be switched off */
__ufshcd_setup_clocks(hba, false, true);
- hba->clk_gating.state = CLKS_OFF;
- trace_ufshcd_clk_gating(dev_name(hba->dev), hba->clk_gating.state);
+ if (ufshcd_is_clkgating_allowed(hba)) {
+ hba->clk_gating.state = CLKS_OFF;
+ trace_ufshcd_clk_gating(dev_name(hba->dev),
+ hba->clk_gating.state);
+ }
/* Put the host controller in low power mode if possible */
ufshcd_hba_vreg_set_lpm(hba);
@@ -8467,6 +8473,11 @@ static int ufshcd_resume(struct ufs_hba *hba, enum
ufs_pm_op pm_op)
if (hba->clk_scaling.is_allowed)
ufshcd_suspend_clkscaling(hba);
ufshcd_setup_clocks(hba, false);
+ if (ufshcd_is_clkgating_allowed(hba)) {
+ hba->clk_gating.state = CLKS_OFF;
+ trace_ufshcd_clk_gating(dev_name(hba->dev),
+ hba->clk_gating.state);
+ }
out:
hba->pm_op_in_progress = 0;
if (ret)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH 7/9] scsi: ufs: Move dumps in IRQ handler to error handler
Sometime dumps in IRQ handler are heavy enough to cause system stability
issues, move them to error handler and only print basic host regs here.
Signed-off-by: Can Guo
Reviewed-by: Bean Huo
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ed24582..602c746 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5696,6 +5696,19 @@ static void ufshcd_err_handler(struct work_struct *work)
UFSHCD_UIC_DL_TCx_REPLAY_ERROR
needs_reset = true;
+ if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR |
+ UFSHCD_UIC_HIBERN8_MASK)) {
+ bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR);
+
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+ ufshcd_print_host_state(hba);
+ ufshcd_print_pwr_info(hba);
+ ufshcd_print_host_regs(hba);
+ ufshcd_print_tmrs(hba, hba->outstanding_tasks);
+ ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt);
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ }
+
/*
* if host reset is required then skip clearing the pending
* transfers forcefully because they will get cleared during
@@ -5915,18 +5928,12 @@ static irqreturn_t ufshcd_check_errors(struct ufs_hba
*hba)
/* dump controller state before resetting */
if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) {
- bool pr_prdt = !!(hba->saved_err &
- SYSTEM_BUS_FATAL_ERROR);
-
dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err
0x%x\n",
__func__, hba->saved_err,
hba->saved_uic_err);
-
- ufshcd_print_host_regs(hba);
+ ufshcd_dump_regs(hba, 0, UFSHCI_REG_SPACE_SIZE,
+"host_regs: ");
ufshcd_print_pwr_info(hba);
- ufshcd_print_tmrs(hba, hba->outstanding_tasks);
- ufshcd_print_trs(hba, hba->outstanding_reqs,
- pr_prdt);
}
ufshcd_schedule_eh_work(hba);
retval |= IRQ_HANDLED;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH 5/9] scsi: ufs: Fix concurrency of error handler and other error recovery paths
Error recovery can be invoked from multiple paths, including hibern8
enter/exit (from ufshcd_link_recovery), ufshcd_eh_host_reset_handler and
eh_work scheduled from IRQ context. Ultimately, these paths are trying to
invoke ufshcd_reset_and_restore, in either sync or async manner.
Having both sync and async manners at the same time has some problems
- If link recovery happens during ungate work, ufshcd_hold() would be
called recursively. Although commit 53c12d0ef6fcb
("scsi: ufs: fix error recovery after the hibern8 exit failure") [1]
fixed a deadlock due to recursive calls of ufshcd_hold() by adding a
check of eh_in_progress into ufshcd_hold, this check allows eh_work to
run in parallel while link recovery is running.
- Similar concurrency can also happen when error recovery is invoked from
ufshcd_eh_host_reset_handler and ufshcd_link_recovery.
- Concurrency can even happen between eh_works. eh_work, currently queued
on system_wq, is allowed to have multiple instances running in parallel,
but we don't have proper protection for that.
If any of above concurrency happens, error recovery would fail and lead
ufs device and host into bad states. To fix the concurrency problem, this
change queues eh_work on a single threaded workqueue and remove link
recovery calls from hibern8 enter/exit path. Meanwhile, make use of eh_work
in eh_host_reset_handler instead of calling ufshcd_reset_and_restore. This
unifies UFS error recovery mechanism.
In addition, according to the UFSHCI JEDEC spec, hibern8 enter/exit error
occurs when the link is broken. This essentially applies to any power mode
change operations (since they all use PACP_PWR cmds in UniPro layer). So,
in this change, if a power mode change operation (including AH8 enter/exit)
fails, mark link state as UIC_LINK_BROKEN_STATE and schedule the eh_work.
In this case, error handler needs to do a full reset and restore to recover
the link back to active. Before the link state is recovered to active,
ufshcd_uic_pwr_ctrl simply returns -ENOLINK to avoid more errors.
Signed-off-by: Can Guo
Reviewed-by: Bean Huo
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 2d71d23..02d379f00 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -16,6 +16,7 @@ static const char *ufschd_uic_link_state_to_string(
case UIC_LINK_OFF_STATE:return "OFF";
case UIC_LINK_ACTIVE_STATE: return "ACTIVE";
case UIC_LINK_HIBERN8_STATE:return "HIBERN8";
+ case UIC_LINK_BROKEN_STATE: return "BROKEN";
default:return "UNKNOWN";
}
}
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 71c650f..2604016 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -228,6 +228,7 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, bool
scale_up);
static irqreturn_t ufshcd_intr(int irq, void *__hba);
static int ufshcd_change_power_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *pwr_mode);
+static void ufshcd_schedule_eh_work(struct ufs_hba *hba);
static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
@@ -1571,11 +1572,6 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
spin_lock_irqsave(hba->host->host_lock, flags);
hba->clk_gating.active_reqs++;
- if (ufshcd_eh_in_progress(hba)) {
- spin_unlock_irqrestore(hba->host->host_lock, flags);
- return 0;
- }
-
start:
switch (hba->clk_gating.state) {
case CLKS_ON:
@@ -1653,6 +1649,7 @@ static void ufshcd_gate_work(struct work_struct *work)
struct ufs_hba *hba = container_of(work, struct ufs_hba,
clk_gating.gate_work.work);
unsigned long flags;
+ int ret;
spin_lock_irqsave(hba->host->host_lock, flags);
/*
@@ -1679,8 +1676,11 @@ static void ufshcd_gate_work(struct work_struct *work)
/* put the link into hibern8 mode before turning off clocks */
if (ufshcd_can_hibern8_during_gating(hba)) {
- if (ufshcd_uic_hibern8_enter(hba)) {
+ ret = ufshcd_uic_hibern8_enter(hba);
+ if (ret) {
hba->clk_gating.state = CLKS_ON;
+ dev_err(hba->dev, "%s: hibern8 enter failed %d\n",
+ __func__, ret);
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
goto out;
@@ -1725,11 +1725,10 @@ static void __ufshcd_release(struct ufs_hba *hba)
hba->clk_gating.active_reqs--;
- if (hba->clk_gating.active_reqs || hba->clk_gating.is_suspended
- || hba->ufshcd_state !=
[PATCH 8/9] scsi: ufs: Fix a racing problem btw error handler and runtime PM ops
Current IRQ handler blocks scsi requests before scheduling eh_work, when
error handler calls pm_runtime_get_sync, if ufshcd_suspend/resume sends a
scsi cmd, most likely the SSU cmd, since scsi requests are blocked,
pm_runtime_get_sync() will never return because ufshcd_suspend/reusme is
blocked by the scsi cmd. Some changes and code re-arrangement can be made
to resolve it.
o In queuecommand path, hba->ufshcd_state check and ufshcd_send_command
should stay into the same spin lock. This is to make sure that no more
commands leak into doorbell after hba->ufshcd_state is changed.
o Don't block scsi requests before error handler starts to run, let error
handler block scsi requests when it is ready to start error recovery.
o Don't let scsi layer keep requeuing the scsi cmds sent from hba runtime
PM ops, let them pass or fail them. Let them pass if eh_work is scheduled
due to non-fatal errors. Fail them if eh_work is scheduled due to fatal
errors, otherwise the cmds may eventually time out since UFS is in bad
state, which gets error handler blocked for too long. If we fail the scsi
cmds sent from hba runtime PM ops, hba runtime PM ops fails too, but it
does not hurt since error handler can recover hba runtime PM error.
Signed-off-by: Can Guo
Reviewed-by: Bean Huo
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 602c746..9ebb5cd 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -126,7 +126,8 @@ enum {
UFSHCD_STATE_RESET,
UFSHCD_STATE_ERROR,
UFSHCD_STATE_OPERATIONAL,
- UFSHCD_STATE_EH_SCHEDULED,
+ UFSHCD_STATE_EH_SCHEDULED_FATAL,
+ UFSHCD_STATE_EH_SCHEDULED_NON_FATAL,
};
/* UFSHCD error handling flags */
@@ -2515,34 +2516,6 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
if (!down_read_trylock(>clk_scaling_lock))
return SCSI_MLQUEUE_HOST_BUSY;
- spin_lock_irqsave(hba->host->host_lock, flags);
- switch (hba->ufshcd_state) {
- case UFSHCD_STATE_OPERATIONAL:
- break;
- case UFSHCD_STATE_EH_SCHEDULED:
- case UFSHCD_STATE_RESET:
- err = SCSI_MLQUEUE_HOST_BUSY;
- goto out_unlock;
- case UFSHCD_STATE_ERROR:
- set_host_byte(cmd, DID_ERROR);
- cmd->scsi_done(cmd);
- goto out_unlock;
- default:
- dev_WARN_ONCE(hba->dev, 1, "%s: invalid state %d\n",
- __func__, hba->ufshcd_state);
- set_host_byte(cmd, DID_BAD_TARGET);
- cmd->scsi_done(cmd);
- goto out_unlock;
- }
-
- /* if error handling is in progress, don't issue commands */
- if (ufshcd_eh_in_progress(hba)) {
- set_host_byte(cmd, DID_ERROR);
- cmd->scsi_done(cmd);
- goto out_unlock;
- }
- spin_unlock_irqrestore(hba->host->host_lock, flags);
-
hba->req_abort_count = 0;
err = ufshcd_hold(hba, true);
@@ -2578,11 +2551,51 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
/* Make sure descriptors are ready before ringing the doorbell */
wmb();
- /* issue command to the controller */
spin_lock_irqsave(hba->host->host_lock, flags);
+ switch (hba->ufshcd_state) {
+ case UFSHCD_STATE_OPERATIONAL:
+ case UFSHCD_STATE_EH_SCHEDULED_NON_FATAL:
+ break;
+ case UFSHCD_STATE_EH_SCHEDULED_FATAL:
+ /*
+* pm_runtime_get_sync() is used at error handling preparation
+* stage. If a scsi cmd, e.g. the SSU cmd, is sent from hba's
+* PM ops, it can never be finished if we let SCSI layer keep
+* retrying it, which gets err handler stuck forever. Neither
+* can we let the scsi cmd pass through, because UFS is in bad
+* state, the scsi cmd may eventually time out, which will get
+* err handler blocked for too long. So, just fail the scsi cmd
+* sent from PM ops, err handler can recover PM error anyways.
+*/
+ if (hba->pm_op_in_progress) {
+ hba->force_reset = true;
+ set_host_byte(cmd, DID_BAD_TARGET);
+ goto out_compl_cmd;
+ }
+ fallthrough;
+ case UFSHCD_STATE_RESET:
+ err = SCSI_MLQUEUE_HOST_BUSY;
+ goto out_compl_cmd;
+ case UFSHCD_STATE_ERROR:
+ set_host_byte(cmd, DID_ERROR);
+ goto out_compl_cmd;
+ default:
+ dev_WARN_ONCE(hba->dev, 1, "%s: invalid state %d\n",
+ __func__, hba->ufshcd_state);
+ set_host_byte(cmd, DID_BAD_TARGET);
+ goto out_compl_cmd;
+ }
ufshcd_send_command(hba,
[PATCH 9/9] scsi: ufs: Properly release resources if a task is aborted successfully
In current UFS task abort hook, namely ufshcd_abort(), if one task is
aborted successfully, clk_gating.active_reqs held by this task is not
decreased, which makes clk_gating.active_reqs stay above zero forever,
thus clock gating would never happen. Instead of releasing resources of
one task "manually", use the existing func __ufshcd_transfer_req_compl().
This change can also eliminate possible racing of scsi_dma_unmap() from
the real completion in IRQ handler path.
Fixes: 5a0b0cb9bee76 ("ufs: Add support for clock gating")
Signed-off-by: Can Guo
CC: Stanley Chu
Reviewed-by: Stanley Chu
Reviewed-by: Asutosh Das
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9ebb5cd..efb40b1 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6636,11 +6636,8 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
goto out;
}
- scsi_dma_unmap(cmd);
-
spin_lock_irqsave(host->host_lock, flags);
- ufshcd_outstanding_req_clear(hba, tag);
- hba->lrb[tag].cmd = NULL;
+ __ufshcd_transfer_req_compl(hba, (1UL << tag));
spin_unlock_irqrestore(host->host_lock, flags);
out:
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH 4/9] scsi: ufs: Add some debug infos to ufshcd_print_host_state
The infos of the last interrupt status and its timestamp are very helpful
when debug system stability issues, e.g. IRQ starvation, so add them to
ufshcd_print_host_state. Meanwhile, UFS device infos like model name and
its FW version also come in handy during debug. In addition, this change
makes cleanup to some prints in ufshcd_print_host_regs as similar prints
are already available in ufshcd_print_host_state.
Signed-off-by: Can Guo
Reviewed-by: Avri Altman
Reviewed-by: Hongwu Su
Reviewed-by: Asutosh Das
Reviewed-by: Stanley Chu
Reviewed-by: Bean Huo
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5acb38c..71c650f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -411,15 +411,6 @@ static void ufshcd_print_err_hist(struct ufs_hba *hba,
static void ufshcd_print_host_regs(struct ufs_hba *hba)
{
ufshcd_dump_regs(hba, 0, UFSHCI_REG_SPACE_SIZE, "host_regs: ");
- dev_err(hba->dev, "hba->ufs_version = 0x%x, hba->capabilities = 0x%x\n",
- hba->ufs_version, hba->capabilities);
- dev_err(hba->dev,
- "hba->outstanding_reqs = 0x%x, hba->outstanding_tasks = 0x%x\n",
- (u32)hba->outstanding_reqs, (u32)hba->outstanding_tasks);
- dev_err(hba->dev,
- "last_hibern8_exit_tstamp at %lld us, hibern8_exit_cnt = %d\n",
- ktime_to_us(hba->ufs_stats.last_hibern8_exit_tstamp),
- hba->ufs_stats.hibern8_exit_cnt);
ufshcd_print_err_hist(hba, >ufs_stats.pa_err, "pa_err");
ufshcd_print_err_hist(hba, >ufs_stats.dl_err, "dl_err");
@@ -438,8 +429,6 @@ static void ufshcd_print_host_regs(struct ufs_hba *hba)
ufshcd_print_err_hist(hba, >ufs_stats.host_reset, "host_reset");
ufshcd_print_err_hist(hba, >ufs_stats.task_abort, "task_abort");
- ufshcd_print_clk_freqs(hba);
-
ufshcd_vops_dbg_register_dump(hba);
}
@@ -499,6 +488,8 @@ static void ufshcd_print_tmrs(struct ufs_hba *hba, unsigned
long bitmap)
static void ufshcd_print_host_state(struct ufs_hba *hba)
{
+ struct scsi_device *sdev_ufs = hba->sdev_ufs_device;
+
dev_err(hba->dev, "UFS Host state=%d\n", hba->ufshcd_state);
dev_err(hba->dev, "outstanding reqs=0x%lx tasks=0x%lx\n",
hba->outstanding_reqs, hba->outstanding_tasks);
@@ -511,12 +502,24 @@ static void ufshcd_print_host_state(struct ufs_hba *hba)
dev_err(hba->dev, "Auto BKOPS=%d, Host self-block=%d\n",
hba->auto_bkops_enabled, hba->host->host_self_blocked);
dev_err(hba->dev, "Clk gate=%d\n", hba->clk_gating.state);
+ dev_err(hba->dev,
+ "last_hibern8_exit_tstamp at %lld us, hibern8_exit_cnt=%d\n",
+ ktime_to_us(hba->ufs_stats.last_hibern8_exit_tstamp),
+ hba->ufs_stats.hibern8_exit_cnt);
+ dev_err(hba->dev, "last intr at %lld us, last intr status=0x%x\n",
+ ktime_to_us(hba->ufs_stats.last_intr_ts),
+ hba->ufs_stats.last_intr_status);
dev_err(hba->dev, "error handling flags=0x%x, req. abort count=%d\n",
hba->eh_flags, hba->req_abort_count);
- dev_err(hba->dev, "Host capabilities=0x%x, caps=0x%x\n",
- hba->capabilities, hba->caps);
+ dev_err(hba->dev, "hba->ufs_version=0x%x, Host capabilities=0x%x,
caps=0x%x\n",
+ hba->ufs_version, hba->capabilities, hba->caps);
dev_err(hba->dev, "quirks=0x%x, dev. quirks=0x%x\n", hba->quirks,
hba->dev_quirks);
+ if (sdev_ufs)
+ dev_err(hba->dev, "UFS dev info: %.8s %.16s rev %.4s\n",
+ sdev_ufs->vendor, sdev_ufs->model, sdev_ufs->rev);
+
+ ufshcd_print_clk_freqs(hba);
}
/**
@@ -5951,6 +5954,8 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
spin_lock(hba->host->host_lock);
intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+ hba->ufs_stats.last_intr_status = intr_status;
+ hba->ufs_stats.last_intr_ts = ktime_get();
/*
* There could be max of hba->nutrs reqs in flight and in worst case
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index b2ef18f..b7f54af 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -409,6 +409,8 @@ struct ufs_err_reg_hist {
/**
* struct ufs_stats - keeps usage/err statistics
+ * @last_intr_status: record the last interrupt status.
+ * @last_intr_ts: record the last interrupt timestamp.
* @hibern8_exit_cnt: Counter to keep track of number of exits,
* reset this after link-startup.
* @last_hibern8_exit_tstamp: Set time after the hibern8 exit.
@@ -428,6 +430,9 @@ struct ufs_err_reg_hist {
* @tsk_abort: tracks task abort events
*/
struct ufs_stats {
+ u32 last_intr_status;
+ ktime_t last_intr_ts;
+
u32 hibern8_exit_cnt;
ktime_t last_hibern8_exit_tstamp;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora
Re: [PATCH v6 4/4] SFH: Create HID report to Enable support of AMD sensor fusion Hub (SFH)
Hi Sandeep,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8 next-20200807]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sandeep-Singh/SFH-Add-Support-for-AMD-Sensor-Fusion-Hub/20200809-182729
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
06a81c1c7db9bd5de0bd38cd5acc44bb22b99150
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/hid/amd-sfh-hid/amdsfh_hid_client.c: In function
'amd_sfh_hid_client_init':
>> drivers/hid/amd-sfh-hid/amdsfh_hid_client.c:140:6: warning: variable 'rc'
>> set but not used [-Wunused-but-set-variable]
140 | int rc, i;
| ^~
vim +/rc +140 drivers/hid/amd-sfh-hid/amdsfh_hid_client.c
6d2f42dac8a703 Sandeep Singh 2020-08-09 131
6d2f42dac8a703 Sandeep Singh 2020-08-09 132 int
amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
6d2f42dac8a703 Sandeep Singh 2020-08-09 133 {
6d2f42dac8a703 Sandeep Singh 2020-08-09 134struct amdtp_cl_data *cl_data =
privdata->cl_data;
6d2f42dac8a703 Sandeep Singh 2020-08-09 135struct amd_mp2_sensor_info info;
6d2f42dac8a703 Sandeep Singh 2020-08-09 136struct device *dev;
6d2f42dac8a703 Sandeep Singh 2020-08-09 137u32 feature_report_size;
6d2f42dac8a703 Sandeep Singh 2020-08-09 138u32 input_report_size;
6d2f42dac8a703 Sandeep Singh 2020-08-09 139u8 cl_idx;
6d2f42dac8a703 Sandeep Singh 2020-08-09 @140int rc, i;
6d2f42dac8a703 Sandeep Singh 2020-08-09 141
6d2f42dac8a703 Sandeep Singh 2020-08-09 142dev = >pdev->dev;
6d2f42dac8a703 Sandeep Singh 2020-08-09 143cl_data =
kzalloc(sizeof(*cl_data), GFP_KERNEL);
6d2f42dac8a703 Sandeep Singh 2020-08-09 144if (!cl_data)
6d2f42dac8a703 Sandeep Singh 2020-08-09 145return -ENOMEM;
6d2f42dac8a703 Sandeep Singh 2020-08-09 146
6d2f42dac8a703 Sandeep Singh 2020-08-09 147cl_data->num_hid_devices =
amd_mp2_get_sensor_num(privdata, _data->sensor_idx[0]);
6d2f42dac8a703 Sandeep Singh 2020-08-09 148
6d2f42dac8a703 Sandeep Singh 2020-08-09 149
INIT_DELAYED_WORK(_data->work, amd_sfh_work);
6d2f42dac8a703 Sandeep Singh 2020-08-09 150
INIT_DELAYED_WORK(_data->work_buffer, amd_sfh_work_buffer);
6d2f42dac8a703 Sandeep Singh 2020-08-09 151INIT_LIST_HEAD(_list.list);
6d2f42dac8a703 Sandeep Singh 2020-08-09 152
6d2f42dac8a703 Sandeep Singh 2020-08-09 153for (i = 0; i <
cl_data->num_hid_devices; i++) {
6d2f42dac8a703 Sandeep Singh 2020-08-09 154
cl_data->sensor_virt_addr[i] = dma_alloc_coherent(dev, sizeof(int) * 8,
6d2f42dac8a703 Sandeep Singh 2020-08-09 155
_data->sensor_phys_addr[i],
6d2f42dac8a703 Sandeep Singh 2020-08-09 156
GFP_KERNEL);
6d2f42dac8a703 Sandeep Singh 2020-08-09 157cl_data->sensor_sts[i]
= 0;
6d2f42dac8a703 Sandeep Singh 2020-08-09 158
cl_data->sensor_requested_cnt[i] = 0;
6d2f42dac8a703 Sandeep Singh 2020-08-09 159cl_data->cur_hid_dev =
i;
6d2f42dac8a703 Sandeep Singh 2020-08-09 160cl_idx =
cl_data->sensor_idx[i];
6d2f42dac8a703 Sandeep Singh 2020-08-09 161
cl_data->report_descr_sz[i] = get_descr_sz(cl_idx, descr_size);
6d2f42dac8a703 Sandeep Singh 2020-08-09 162if
(!cl_data->report_descr_sz[i])
6d2f42dac8a703 Sandeep Singh 2020-08-09 163return -EINVAL;
6d2f42dac8a703 Sandeep Singh 2020-08-09 164
6d2f42dac8a703 Sandeep Singh 2020-08-09 165feature_report_size =
get_descr_sz(cl_idx, feature_size);
6d2f42dac8a703 Sandeep Singh 2020-08-09 166if
(!feature_report_size)
6d2f42dac8a703 Sandeep Singh 2020-08-09 167return -EINVAL;
6d2f42dac8a703 Sandeep Singh 2020-08-09 168
6d2f42dac8a703 Sandeep Singh 2020-08-09 169input_report_size =
get_descr_sz(cl_idx, input_size);
6d2f42dac8a703 Sandeep Singh 2020-08-09 170if (!input_report_size)
6d2f42dac8a703 Sandeep Singh 2020-08-09 171return -EINVAL;
6d2f42dac8a703 Sandeep Singh 2020-08-09 172
6d2f42dac8a703 Sandeep Singh 2020-08-09 173
Re: Your Assistance For Investment.
Dear Friend, Please, I come to you with good reason. My name is Mr.Dickson Nsebeh, a banker by profession, with position of ( Assistant Manager ) I will be going on retirement end of September 2020. Please can i trust you to release the sum of $9.3 Million Dollars, to you for safe keeping in any account there in your country ?. You will have 40% as your share while 60% will be for me to move into any investment you will suggest for me. Please kindly reply me with your information as stated below for more details and how to execute this transfer to your provided account as soon as possible. Your Full Name... Your Age... Your Home Address.. Your Occupation... Your Country.. Your Cellular N0... Am waiting for your response. God bless you. Mr.Dickson Nsebeh. Reply to> waxso...@yahoo.com
[PATCH] usb: musb: Fix runtime PM race in musb_queue_resume_work
musb_queue_resume_work() would call the provided callback if the runtime
PM status was 'active'. Otherwise, it would enqueue the request if the
hardware was still suspended (musb->is_runtime_suspended is true).
This causes a race with the runtime PM handlers, as it is possible to be
in the case where the runtime PM status is not yet 'active', but the
hardware has been awaken (PM resume function has been called).
When hitting the race, the resume work was not enqueued, which probably
triggered other bugs further down the stack. For instance, a telnet
connection on Ingenic SoCs would result in a 50/50 chance of a
segmentation fault somewhere in the musb code.
Rework the code so that either we call the callback directly if
(musb->is_runtime_suspended == 0), or enqueue the query otherwise.
Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid
context for hdrc glue")
Cc: sta...@vger.kernel.org # v4.9
Signed-off-by: Paul Cercueil
---
drivers/usb/musb/musb_core.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 384a8039a7fd..462c10d7455a 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2241,32 +2241,35 @@ int musb_queue_resume_work(struct musb *musb,
{
struct musb_pending_work *w;
unsigned long flags;
+ bool is_suspended;
int error;
if (WARN_ON(!callback))
return -EINVAL;
- if (pm_runtime_active(musb->controller))
- return callback(musb, data);
+ spin_lock_irqsave(>list_lock, flags);
+ is_suspended = musb->is_runtime_suspended;
+
+ if (is_suspended) {
+ w = devm_kzalloc(musb->controller, sizeof(*w), GFP_ATOMIC);
+ if (!w) {
+ error = -ENOMEM;
+ goto out_unlock;
+ }
- w = devm_kzalloc(musb->controller, sizeof(*w), GFP_ATOMIC);
- if (!w)
- return -ENOMEM;
+ w->callback = callback;
+ w->data = data;
- w->callback = callback;
- w->data = data;
- spin_lock_irqsave(>list_lock, flags);
- if (musb->is_runtime_suspended) {
list_add_tail(>node, >pending_list);
error = 0;
- } else {
- dev_err(musb->controller, "could not add resume work %p\n",
- callback);
- devm_kfree(musb->controller, w);
- error = -EINPROGRESS;
}
+
+out_unlock:
spin_unlock_irqrestore(>list_lock, flags);
+ if (!is_suspended)
+ error = callback(musb, data);
+
return error;
}
EXPORT_SYMBOL_GPL(musb_queue_resume_work);
--
2.28.0
RE: [PATCH] tools/thermal: tmon: include pthread and time headers in tmon.h
> > -Original Message- > > From: Florian Fainelli > > Sent: Thursday, June 18, 2020 8:23 AM > > To: Markus Mayer ; Daniel Lezcano > > ; Pawnikar, Sumeet R > > ; Zhang, Rui ; Brian > > Norris > > Cc: Broadcom Kernel List ; Linux > > Kernel Mailing List > > Subject: Re: [PATCH] tools/thermal: tmon: include pthread and time headers > > in tmon.h > > > > > > > > On 6/17/2020 4:58 PM, Markus Mayer wrote: > > > Include sys/time.h and pthread.h in tmon.h, so that types > > > "pthread_mutex_t" and "struct timeval tv" are known when tmon.h > > > references them. > > > > > > Without these headers, compiling tmon against musl-libc will fail with > > > these errors: > > > > > > In file included from sysfs.c:31:0: > > > tmon.h:47:8: error: unknown type name 'pthread_mutex_t' > > > extern pthread_mutex_t input_lock; > > > ^~~ > > > make[3]: *** [: sysfs.o] Error 1 > > > make[3]: *** Waiting for unfinished jobs > > > In file included from tui.c:31:0: > > > tmon.h:54:17: error: field 'tv' has incomplete type > > > struct timeval tv; > > > ^~ > > > make[3]: *** [: tui.o] Error 1 > > > make[2]: *** [Makefile:83: tmon] Error 2 > > > > > > Signed-off-by: Markus Mayer > > > > Acked-by: Florian Fainelli > > -- > > Florian > > Reviewed-by: Sumeet Pawnikar > > Thanks, > Sumeet. I've tested this patch with musl-libc for the same arch. It works like a charm. Acked-by: Alejandro González Tested-by: Alejandro González
[GIT PULL] pin control changes for the v5.9 kernel cycle
Hi Linus, here is the big bulk of pin control changes for the v5.9 kernel cycle, nothing is particularly interesting. I expect you to see two conflicts: drivers/pinctrl/intel/pinctrl-baytrail.c - no idea what this is about as both HEAD and mine look the same to human eyes, I suppose whitespace. Take whichever version you like. drivers/pinctrl/pinctrl-single.c - use my version, the documentation fix shall prevail. There is a revert I made, it was because I by mistake merged a GPIO patch to the pin control tree and then later realized my mistake, but other development was done on top. Sorry. Please pull it in! Yours, Linus Walleij The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git tags/pinctrl-v5.9-1 for you to fetch changes up to 7ee193e2dda3f48b692fad46ab9df90e99e7b811: dt-bindings: pinctrl: add bindings for MediaTek MT6779 SoC (2020-08-04 01:29:58 +0200) This is the bulk of the pin control changes for the v5.9 kernel series: Core changes: - The GPIO patch "gpiolib: Introduce for_each_requested_gpio_in_range() macro" was put in an immutable branch and merged into the pinctrl tree as well. We see these changes also here. - Improved debug output for pins used as GPIO. New drivers: - Ocelot Sparx5 SoC driver. - Intel Emmitsburg SoC subdriver. - Intel Tiger Lake-H SoC subdriver. - Qualcomm PM660 SoC subdriver. - Renesas SH-PFC R8A774E1 subdriver. Driver improvements: - Linear improvement and cleanups of the Intel drivers for Cherryview, Lynxpoint, Baytrail etc. Improved locking among other things. - Renesas SH-PFC has added support for RPC pins, groups, and functions to r8a77970 and r8a77980. - The newere Freescale (now NXP) i.MX8 pin controllers have been modularized. This is driven by the Google Android GKI initiative I think. - Open drain support for pins on the Qualcomm IPQ4019. - The Ingenic driver can handle both edges IRQ detection. - A big slew of documentation fixes all over the place. - A few irqchip template conversions by yours truly. Alexander A. Klimov (2): pinctrl: rockchip: Replace HTTP links with HTTPS ones pinctl: ti: iodelay: Replace HTTP links with HTTPS ones Alexandre Torgue (2): pinctrl: stm32: return proper error code in pin_config_set pinctrl: stm32: add possibility to configure pins individually Andrew Jeffery (2): pinctrl: aspeed: Improve debug output pinctrl: aspeed: Describe the heartbeat function on ball Y23 Andy Shevchenko (26): gpiolib: Introduce for_each_requested_gpio_in_range() macro ARM/orion/gpio: Make use of for_each_requested_gpio() gpio: mvebu: Make use of for_each_requested_gpio() gpio: xra1403: Make use of for_each_requested_gpio() pinctrl: at91: Make use of for_each_requested_gpio() pinctrl: cherryview: Introduce chv_readl() helper pinctrl: cherryview: Introduce helpers to IO with common registers pinctrl: cherryview: Convert chv_writel() to use chv_padreg() pinctrl: intel: Allow drivers to define total amount of IRQs per community pinctrl: intel: Allow drivers to define ACPI address space ID pinctrl: cherryview: Re-use data structures from pinctrl-intel.h (part 3) pinctrl: intel: Disable input and output buffer when switching to GPIO pinctrl: intel: Reduce scope of the lock pinctrl: intel: Make use of IRQ_RETVAL() pinctrl: intel: Get rid of redundant 'else' in intel_config_set_debounce() pinctrl: intel: Drop the only label in the code for consistency pinctrl: intel: Split intel_config_get() to three functions pinctrl: intel: Protect IO in few call backs by lock pinctrl: intel: Make use of for_each_requested_gpio_in_range() pinctrl: lynxpoint: Make use of for_each_requested_gpio() pinctrl: lynxpoint: Introduce helpers to enable or disable input pinctrl: lynxpoint: Drop no-op ACPI_PTR() call pinctrl: baytrail: Drop no-op ACPI_PTR() call pinctrl: merrifield: Update pin names in accordance with official list pinctrl: merrifield: Add I²S bus 2 pins to groups and functions pinctrl: intel: Add Intel Emmitsburg pin controller support Andy Teng (1): dt-bindings: pinctrl: add bindings for MediaTek MT6779 SoC Anson Huang (9): pinctrl: imx: Support i.MX8 SoCs pinctrl driver built as module pinctrl: imx: scu: Support i.MX8 SCU SoCs pinctrl driver built as module pinctrl: imx8mm: Support building as module pinctrl: imx8mn: Support building as module pinctrl: imx8mq: Support building as module pinctrl: imx8mp: Support building as module pinctrl: imx8qxp: Support building as module
Re: [PATCH v4 1/3] iio: accel: adxl372: Add support for FIFO peak mode
On Mon, 3 Aug 2020 20:22:17 +0300
wrote:
> From: Stefan Popa
>
> By default, if all three channels (x, y, z) are enabled, sample sets of
> concurrent 3-axis data is stored in the FIFO. This patch adds the option
> to configure the FIFO to store peak acceleration (x, y and z) of every
> over-threshold event. When pushing to iio buffer we push only enabled
> axis data.
>
> Signed-off-by: Stefan Popa
Hi Stefan,
A few things inline I missed on previous reads.
Jonathan
> ---
> drivers/iio/accel/adxl372.c | 72 +++--
> 1 file changed, 70 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index 67b8817995c0..cce25cde6252 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -133,6 +133,9 @@
>
> /* The ADXL372 includes a deep, 512 sample FIFO buffer */
> #define ADXL372_FIFO_SIZE512
> +#define ADXL372_X_AXIS_EN(x) (((x) >> 0) & 0x1)
I hadn't noticed this before, but this is a slightly odd construct.
Would be more normal to check against the mask directly, so
something like...
((x) & BIT(0))
((x) & BIT(1))
> +#define ADXL372_Y_AXIS_EN(x) (((x) >> 1) & 0x1)
> +#define ADXL372_Z_AXIS_EN(x) (((x) >> 2) & 0x1)
>
> /*
> * At +/- 200g with 12-bit resolution, scale is computed as:
> @@ -251,8 +254,10 @@ struct adxl372_state {
> struct device *dev;
> struct regmap *regmap;
> struct iio_trigger *dready_trig;
> + struct iio_trigger *peak_datardy_trig;
> enum adxl372_fifo_mode fifo_mode;
> enum adxl372_fifo_formatfifo_format;
> + unsigned intfifo_axis_mask;
> enum adxl372_op_modeop_mode;
> enum adxl372_act_proc_mode act_proc_mode;
> enum adxl372_odrodr;
> @@ -264,6 +269,7 @@ struct adxl372_state {
> u8 int2_bitmask;
> u16 watermark;
> __be16 fifo_buf[ADXL372_FIFO_SIZE];
> + boolpeak_fifo_mode_en;
> };
>
> static const unsigned long adxl372_channel_masks[] = {
> @@ -522,6 +528,22 @@ static int adxl372_get_status(struct adxl372_state *st,
> return ret;
> }
>
> +static void adxl372_arrange_axis_data(struct adxl372_state *st, __be16
> *sample)
> +{
> + __be16 axis_sample[3];
> + int i = 0;
> +
> + memset(axis_sample, 0, 3 * sizeof(__be16));
> + if (ADXL372_X_AXIS_EN(st->fifo_axis_mask))
> + axis_sample[i++] = sample[0];
> + if (ADXL372_Y_AXIS_EN(st->fifo_axis_mask))
> + axis_sample[i++] = sample[1];
> + if (ADXL372_Z_AXIS_EN(st->fifo_axis_mask))
> + axis_sample[i++] = sample[2];
> +
> + memcpy(sample, axis_sample, 3 * sizeof(__be16));
> +}
> +
> static irqreturn_t adxl372_trigger_handler(int irq, void *p)
> {
> struct iio_poll_func *pf = p;
> @@ -553,8 +575,12 @@ static irqreturn_t adxl372_trigger_handler(int irq, void
> *p)
> goto err;
>
> /* Each sample is 2 bytes */
> - for (i = 0; i < fifo_entries; i += st->fifo_set_size)
> + for (i = 0; i < fifo_entries; i += st->fifo_set_size) {
> + /* filter peak detection data */
> + if (st->peak_fifo_mode_en)
> + adxl372_arrange_axis_data(st, >fifo_buf[i]);
> iio_push_to_buffers(indio_dev, >fifo_buf[i]);
> + }
> }
> err:
> iio_trigger_notify_done(indio_dev->trig);
> @@ -815,13 +841,22 @@ static int adxl372_buffer_postenable(struct iio_dev
> *indio_dev)
> }
>
> st->fifo_format = adxl372_axis_lookup_table[i].fifo_format;
> + st->fifo_axis_mask = adxl372_axis_lookup_table[i].bits;
> st->fifo_set_size = bitmap_weight(indio_dev->active_scan_mask,
> indio_dev->masklength);
> +
> + /* Configure the FIFO to store sets of impact event peak. */
> + if (st->peak_fifo_mode_en) {
> + st->fifo_set_size = 3;
> + st->fifo_format = ADXL372_XYZ_PEAK_FIFO;
> + }
> +
> /*
>* The 512 FIFO samples can be allotted in several ways, such as:
>* 170 sample sets of concurrent 3-axis data
>* 256 sample sets of concurrent 2-axis data (user selectable)
>* 512 sample sets of single-axis data
> + * 170 sets of impact event peak (x, y, z)
>*/
> if ((st->watermark * st->fifo_set_size) > ADXL372_FIFO_SIZE)
> st->watermark = (ADXL372_FIFO_SIZE / st->fifo_set_size);
> @@ -876,7 +911,7 @@ static int adxl372_validate_trigger(struct iio_dev
> *indio_dev,
> {
> struct adxl372_state *st = iio_priv(indio_dev);
>
> - if (st->dready_trig != trig)
> + if
Re: [PATCH v4 2/3] iio: accel: adxl372: add event interface
On Mon, 3 Aug 2020 20:22:18 +0300
wrote:
> From: Alexandru Tachici
>
> Currently the driver configures adxl372 to work in loop mode.
> The inactivity and activity timings decide how fast the chip
> will loop through the awake and waiting states and the
> thresholds on x,y,z axis decide when activity or inactivity
> will be detected.
>
> This patch adds standard events sysfs entries for the inactivity
> and activity timings: thresh_falling_period/thresh_rising_period
> and for the in_accel_x_thresh_falling/rising_value.
>
> Signed-off-by: Alexandru Tachici
Ah. This makes sense of some of the elements in the previous patch that
didn't stand alone. I'd take the easy approach and just combine the two
patches. Alternative would be to move some of bits that are refactored
to use int1_bitmask into a precursor to both patches that is just a
refactor with no functional changes. At the moment it's not possible
to review the patches independently.
Jonathan
> ---
> drivers/iio/accel/adxl372.c | 256 +++-
> 1 file changed, 250 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index cce25cde6252..644c409862b5 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -5,6 +5,7 @@
> * Copyright 2018 Analog Devices Inc.
> */
>
> +#include
> #include
> #include
> #include
> @@ -113,6 +114,11 @@
> #define ADXL372_STATUS_1_AWAKE(x)(((x) >> 6) & 0x1)
> #define ADXL372_STATUS_1_ERR_USR_REGS(x) (((x) >> 7) & 0x1)
>
> +/* ADXL372_STATUS_2 */
> +#define ADXL372_STATUS_2_INACT(x)(((x) >> 4) & 0x1)
> +#define ADXL372_STATUS_2_ACT(x) (((x) >> 5) & 0x1)
> +#define ADXL372_STATUS_2_AC2(x) (((x) >> 6) & 0x1)
> +
> /* ADXL372_INT1_MAP */
> #define ADXL372_INT1_MAP_DATA_RDY_MSKBIT(0)
> #define ADXL372_INT1_MAP_DATA_RDY_MODE(x)(((x) & 0x1) << 0)
> @@ -131,6 +137,14 @@
> #define ADXL372_INT1_MAP_LOW_MSK BIT(7)
> #define ADXL372_INT1_MAP_LOW_MODE(x) (((x) & 0x1) << 7)
>
> +/* ADX372_THRESH */
> +#define ADXL372_THRESH_VAL_H_MSK GENMASK(10, 3)
> +#define ADXL372_THRESH_VAL_H_SEL(x) \
> + FIELD_GET(ADXL372_THRESH_VAL_H_MSK, x)
#define ADXL372_THRESH_VAL_H_SEL(x)
FIELD_GET(ADXL372_THRESH_VAL_H_MSK, x)
Given we can now got up to 100 chars, let us making this more readable and keep
them
on single lines.
> +#define ADXL372_THRESH_VAL_L_MSK GENMASK(2, 0)
> +#define ADXL372_THRESH_VAL_L_SEL(x) \
> + FIELD_GET(ADXL372_THRESH_VAL_L_MSK, x)
> +
> /* The ADXL372 includes a deep, 512 sample FIFO buffer */
> #define ADXL372_FIFO_SIZE512
> #define ADXL372_X_AXIS_EN(x) (((x) >> 0) & 0x1)
> @@ -225,6 +239,22 @@ static const struct adxl372_axis_lookup
> adxl372_axis_lookup_table[] = {
> { BIT(0) | BIT(1) | BIT(2), ADXL372_XYZ_FIFO },
> };
>
> +static const struct iio_event_spec adxl372_events[] = {
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_RISING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE),
> + .mask_shared_by_all = BIT(IIO_EV_INFO_PERIOD) |
> + BIT(IIO_EV_INFO_ENABLE),
> + }, {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_FALLING,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE),
> + .mask_shared_by_all = BIT(IIO_EV_INFO_PERIOD) |
> + BIT(IIO_EV_INFO_ENABLE),
> + },
> +};
> +
> #define ADXL372_ACCEL_CHANNEL(index, reg, axis) {\
> .type = IIO_ACCEL, \
> .address = reg, \
> @@ -241,6 +271,8 @@ static const struct adxl372_axis_lookup
> adxl372_axis_lookup_table[] = {
> .storagebits = 16, \
> .shift = 4, \
> }, \
> + .event_spec = adxl372_events, \
> + .num_event_specs = ARRAY_SIZE(adxl372_events) \
> }
>
> static const struct iio_chan_spec adxl372_channels[] = {
> @@ -270,6 +302,7 @@ struct adxl372_state {
> u16 watermark;
> __be16 fifo_buf[ADXL372_FIFO_SIZE];
> boolpeak_fifo_mode_en;
> + struct mutexthreshold_m; /* lock for threshold */
> };
>
> static const unsigned long adxl372_channel_masks[] = {
> @@ -281,6 +314,49 @@ static const unsigned long adxl372_channel_masks[] = {
> 0
> };
>
> +static ssize_t adxl372_read_threshold_value(struct iio_dev *indio_dev,
> +
Re: [PATCH net-next RFC 01/13] devlink: Add reload level option to devlink reload command
On 8/6/2020 9:25 PM, Jakub Kicinski wrote:
On Wed, 5 Aug 2020 13:02:58 +0200 Jiri Pirko wrote:
Tue, Aug 04, 2020 at 10:39:46PM CEST, k...@kernel.org wrote:
AFAIU the per-driver default is needed because we went too low
level with what the action constitutes. We need maintain the higher
level actions.
The user clearly did not care if FW was reset during devlink reload
before this set, so what has changed? The objective user has is to
Well for mlxsw, the user is used to this flow:
devlink dev flash - flash new fw
devlink dev reload - new fw is activated and reset and driver instances
are re-created.
Ugh, if the current behavior already implies fw-activation for some
drivers then the default has to probably be "do all the things" :S
Okay, so devlink reload default for mlx5 will include also fw-activate
to align with mlxsw default.
Meaning drivers that supports fw-activate will add it to the default.
The flow of devlink reload default on mlx5 will be:
If there is FW image pending and live patch is suitable to apply, do
live patch and driver re-initialization.
If there is FW image pending but live patch doesn't fit do fw-reset and
driver-initialization.
If no FW image pending just do driver-initialization.
I still think I should on top of that add the level option to be
selected by the user if he prefers a specific action, so the uAPI would be:
devlink dev reload [ netns { PID | NAME | ID } ] [ level { fw-live-patch
| driver-reinit |fw-activate } ]
But I am still missing something: fw-activate implies that it will
activate a new FW image stored on flash, pending activation. What if the
user wants to reset and reload the FW if no new FW pending ? Should we
add --force option to fw-activate level ?
activate their config / FW / move to different net ns.
Reloading the driver or resetting FW is a low level detail which
achieves different things for different implementations. So it's
not a suitable abstraction -> IOW we need the driver default.
I'm confused. So you think we need the driver default?
No, I'm talking about the state of this patch set. _In this patchset_
we need a driver default because of the unsuitable abstraction.
Better design would not require it.
The work flow for the user is:
0. download fw to /lib/firmware
1. devlink flash $dev $fw
2. if live activation is enabled
yes - devlink reload $dev $live-activate
no - report machine has to be drained for reboot
fw-reset can't be $live-activate, because as Jake said fw-reset does
not activate the new image for Intel. So will we end up per-driver
defaults in the kernel space, and user space maintaining a mapping from
Well, that is what what is Moshe's proposal. Per-driver kernel default..
I'm not sure what we are arguing about then :/
The fact that if I do a pure "driver reload" it will active new
firmware for mlxsw but not for mlx5. In this patchset for mlx5 I need
driver reload fw-reset. And for Intel there is no suitable option.
a driver to what a "level" of reset implies.
I hope this makes things crystal clear. Please explain what problems
you're seeing and extensions you're expecting. A list of user scenarios
you foresee would be v. useful.
Re: [PATCH v4 3/3] docs: iio: Add adxl372 documentation
On Mon, 3 Aug 2020 20:22:19 +0300 wrote: > From: Alexandru Tachici > > Add documentation for adxl372 3-axis accelerometer. > > Signed-off-by: Alexandru Tachici This is ABI docs, so I'd normally expect them in Documentation/ABI/testing/sysfs-bus-iio-accel-adxl372 rather than as part of the main docs. I can kind of see why you want to take advantage of more free form docs, but I'd definitely want to see them in the ABI docs first. Once that is done, then we can see if there is anything left that needs to be documented like you have here. Thanks, Jonathan > --- > Documentation/iio/adxl372.rst | 46 +++ > Documentation/iio/index.rst | 1 + > 2 files changed, 47 insertions(+) > create mode 100644 Documentation/iio/adxl372.rst > > diff --git a/Documentation/iio/adxl372.rst b/Documentation/iio/adxl372.rst > new file mode 100644 > index ..f8fe5f438400 > --- /dev/null > +++ b/Documentation/iio/adxl372.rst > @@ -0,0 +1,46 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +Kernel driver adxl372 > += > + > +Supported chips: > + * Analog Devices ADXL372 > +Prefix: 'adxl372' > +Datasheet: > https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL372.pdf > + > +Author: Stefan Popa > + > + > +Description > +--- > + > +The ADXL372 is an ultralow power, 3-axis, ±200 g MEMS accelerometer > +that consumes 22 μA at a 3200 Hz output data rate (ODR). > + > +The ADXL372 provides 12-bit output data at 100 mg/LSB scale factor. > + > +Using the FIFO Buffer > +- > + > +The ADXL372 includes a deep, 512 sample FIFO buffer. > +The 512 FIFO samples can be allotted in several ways, such as the following: > + > +170 sample sets of concurrent 3-axis data > +256 sample sets of concurrent 2-axis data (see > scan_elements/in_accel_*_en) > +512 sample sets of single-axis data > +170 sets of impact event peak (x, y, z) > + > +By default when using the buffer adxl372 will store all > +acceleration data. To store only the peak acceleration data, the user must > +select the peak data trigger: adxl372-dev0-peak > + > +The user can set the thresholds for each axis for activity and inactivity in: > +- events/in_accel_*_thresh_rising_value > +- events/in_accel_*_thresh_falling_value > + > +An inactivity/activity event is detected when acceleration in all enabled > +axes remains below/above a specified threshold for a specified time. The user > +can set these timings in: > +- events/thresh_falling_period > +- events/thresh_rising_period > + > diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst > index 58b7a4ebac51..3d0acb1eef86 100644 > --- a/Documentation/iio/index.rst > +++ b/Documentation/iio/index.rst > @@ -10,3 +10,4 @@ Industrial I/O > iio_configfs > > ep93xx_adc > + adxl372.rst
Documentation: build failure with sphinx >= 3.0.0: exception: cannot import name 'c_funcptr_sig_re' from 'sphinx.domains.c' (was: Re: Kernel build failed ...SPHINX extension error)
Hi On Thu, Apr 09, 2020 at 05:04:54AM +0530, Bhaskar Chowdhury wrote: > On 13:25 Wed 08 Apr 2020, Jonathan Corbet wrote: > > On Wed, 8 Apr 2020 17:07:05 +0530 > > Bhaskar Chowdhury wrote: > > > > > Extension error: > > > Could not import extension cdomain (exception: cannot import name > > > 'c_funcptr_sig_re' from 'sphinx.domains.c' > > > (/usr/lib/python3.8/site-packages/sphinx/domains/c.py)) > > > Apr 08 16:48:46 enabling CJK for LaTeX builder > > > Apr 08 16:48:46 CC kernel/power/poweroff.o > > > make[1]: *** [Documentation/Makefile:81: htmldocs] Error 2 > > > make: *** [Makefile:1549: htmldocs] Error 2 > > > make: *** Waiting for unfinished jobs > > > > This is weird, to say the least. But I think the "python3.8" in the > > message above says everything you need to know. If you're running with > > an unreleased version of Python, it's not entirely surprising that you > > might run into trouble with a complex package. > > > > jon > > Thank you Jon...will investigate more and keep your suggestion in mind. The problem is actually related to changes happening in Sphinx 3.0.0. There is the followign issue filled upstream: https://github.com/sphinx-doc/sphinx/issues/7421 'c_funcptr_sig_re' was removed upstream in sphinx v3.0.0b1 and so the kernel documentation build fails. This is reproducible with a recent sphinx version (in attached case it is 3.2.0): $ make PYTHON=python3 xmldocs SPHINX xmldocs --> file:///home/build/linux/Documentation/output/xml make[2]: Nothing to be done for 'xml'. Running Sphinx v3.2.0 Extension error: Could not import extension cdomain (exception: cannot import name 'c_funcptr_sig_re' from 'sphinx.domains.c' (/usr/lib/python3/dist-packages/sphinx/domains/c.py)) make[1]: *** [Documentation/Makefile:115: xmldocs] Error 2 make: *** [Makefile:1655: xmldocs] Error 2 Distribution reports related to this issue: https://bugs.debian.org/963636 https://bugs.archlinux.org/task/66178 https://bugs.archlinux.org/task/66156 Regards, Salvatore
[PATCH v3 02/18] gpio: uapi: define uAPI v2
Add a new version of the uAPI to address existing 32/64-bit alignment
issues, add support for debounce and event sequence numbers, allow
requested lines with different configurations, and provide some future
proofing by adding padding reserved for future use.
The alignment issue relates to the gpioevent_data, which packs to different
sizes on 32-bit and 64-bit platforms. That creates problems for 32-bit apps
running on 64-bit kernels. uAPI v2 addresses that particular issue, and
the problem more generally, by adding pad fields that explicitly pad
structs out to 64-bit boundaries, so they will pack to the same size now,
and even if some of the reserved padding is used for __u64 fields in the
future.
The new structs have been analysed with pahole to ensure that they
are sized as expected and contain no implicit padding.
The lack of future proofing in v1 makes it impossible to, for example,
add the debounce feature that is included in v2.
The future proofing is addressed by providing configurable attributes in
line config and reserved padding in all structs for future features.
Specifically, the line request, config, info, info_changed and event
structs receive updated versions and new ioctls.
As the majority of the structs and ioctls were being replaced, it is
opportune to rework some of the other aspects of the uAPI:
v1 has three different flags fields, each with their own separate
bit definitions. In v2 that is collapsed to one - gpio_v2_line_flag.
The handle and event requests are merged into a single request, the line
request, as the two requests were mostly the same other than the edge
detection provided by event requests. As a byproduct, the v2 uAPI allows
for multiple lines producing edge events on the same line handle.
This is a new capability as v1 only supports a single line in an event
request.
As a consequence, there are now only two types of file handle to be
concerned with, the chip and the line, and it is clearer which ioctls
apply to which type of handle.
There is also some minor renaming of fields for consistency compared to
their v1 counterparts, e.g. offset rather than lineoffset or line_offset,
and consumer rather than consumer_label.
Additionally, v1 GPIOHANDLES_MAX becomes GPIO_V2_LINES_MAX in v2 for
clarity, and the gpiohandle_data __u8 array becomes a bitmap in
gpio_v2_line_values.
The v2 uAPI is mostly a reorganisation and extension of v1, so userspace
code, particularly libgpiod, should readily port to it.
Signed-off-by: Kent Gibson
---
Changes since v2:
- relocated commentary into commit description
- hard limit max requested lines to 64 so bitmaps always fit in a single
u64.
- prefix all v2 symbols with GPIO_V2
- 64-bit flag values to ULL
- use __aligned_u64 to ensure 64-bit fields are 64-bit aligned
- support masked get values, as per set values.
Changes since v1:
- lower case V1 and V2, except in capitalized names
- hyphenate 32/64-bit
- rename bitmap field to bits
- drop PAD_SIZE consts in favour of hard coded numbers
- sort includes
- change config flags to __u64
- increase padding of gpioline_event
- relocate GPIOLINE_CHANGED enum into v2 section (is common with v1)
- rework config to collapse direction, drive, bias and edge enums back
into flags and add optional attributes that can be associated with a
subset of the requested lines.
Changes since the RFC:
- document the constraints on array sizes to maintain 32/64 alignment
- add sequence numbers to gpioline_event
- use bitmap for values instead of array of __u8
- gpioline_info_v2 contains gpioline_config instead of its composite fields
- provide constants for all array sizes, especially padding
- renamed "GPIOLINE_FLAG_V2_KERNEL" to "GPIOLINE_FLAG_V2_USED"
- renamed "default_values" to "values"
- made gpioline_direction zero based
- document clock used in gpioline_event timestamp
- add event_buffer_size to gpioline_request
- rename debounce to debounce_period
- rename lines to num_lines
include/uapi/linux/gpio.h | 272 +-
1 file changed, 265 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 285cc10355b2..82e8744b8c3b 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -16,6 +16,8 @@
/*
* The maximum size of name and label arrays.
+ *
+ * Must be a multiple of 8 to ensure 32/64-bit alignment of structs.
*/
#define GPIO_MAX_NAME_SIZE 32
@@ -32,6 +34,247 @@ struct gpiochip_info {
__u32 lines;
};
+/*
+ * Maximum number of requested lines.
+ *
+ * Must be no greater than 64 as bitmaps are limited to 64-bits, and a
+ * multiple of 2 to ensure 32/64-bit alignment of structs.
+ */
+#define GPIO_V2_LINES_MAX 64
+
+/*
+ * The maximum number of configuration attributes associated with a line
+ * request.
+ */
+#define GPIO_V2_LINE_NUM_ATTRS_MAX 10
+
+/**
+ * enum gpio_v2_line_flag - gpio_v2_line_attribute.flags values
+ */
+enum gpio_v2_line_flag
[PATCH v3 04/18] gpiolib: add build option for CDEV v1 ABI
Add a build option to allow the removal of the CDEV v1 ABI. Suggested-by: Bartosz Golaszewski Signed-off-by: Kent Gibson --- This patch is before the v2 implementation, and is non-functional until that patch, as some parts of that patch would be written slightly differently if removing v1 was not considered. Adding this patch after that would necessitate revisiting the v2 changes, so this ordering results in two simpler patches. drivers/gpio/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 8e409b9c33dc..0c62e35cf3a6 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -82,6 +82,18 @@ config GPIO_CDEV If unsure, say Y. +config GPIO_CDEV_V1 + bool "Support GPIO ABI Version 1" + default y + depends on GPIO_CDEV + help + Say Y here to support version 1 of the GPIO CDEV ABI. + + This ABI version is deprecated and will be removed in the future. + Please use the latest ABI for new developments. + + If unsure, say Y. + config GPIO_GENERIC depends on HAS_IOMEM # Only for IOMEM drivers tristate -- 2.28.0
[PATCH v3 05/18] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL
Add support for requesting lines using the GPIO_V2_GET_LINE_IOCTL, and
returning their current values using GPIO_V2_LINE_GET_VALUES_IOCTL.
Signed-off-by: Kent Gibson
---
The struct line implementation is based on the v1 struct linehandle
implementation.
The line_ioctl() is a simple wrapper around line_get_values() here, but
will be extended with other ioctls in subsequent patches.
drivers/gpio/gpiolib-cdev.c | 413
1 file changed, 413 insertions(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index e6c9b78adfc2..4b657492d836 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
+#include
#include
#include
#include
@@ -34,6 +36,7 @@
* GPIO line handle management
*/
+#ifdef CONFIG_GPIO_CDEV_V1
/**
* struct linehandle_state - contains the state of a userspace handle
* @gdev: the GPIO device the handle pertains to
@@ -376,6 +379,390 @@ static int linehandle_create(struct gpio_device *gdev,
void __user *ip)
linehandle_free(lh);
return ret;
}
+#endif /* CONFIG_GPIO_CDEV_V1 */
+
+/**
+ * struct line - contains the state of a userspace line request
+ * @gdev: the GPIO device the line request pertains to
+ * @label: consumer label used to tag descriptors
+ * @num_descs: the number of descriptors held in the descs array
+ * @descs: the GPIO descriptors held by this line request, with @num_descs
+ * elements.
+ */
+struct line {
+ struct gpio_device *gdev;
+ const char *label;
+ u32 num_descs;
+ struct gpio_desc *descs[];
+};
+
+#define GPIO_V2_LINE_BIAS_FLAGS \
+ (GPIO_V2_LINE_FLAG_BIAS_PULL_UP | \
+GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN | \
+GPIO_V2_LINE_FLAG_BIAS_DISABLED)
+
+#define GPIO_V2_LINE_DIRECTION_FLAGS \
+ (GPIO_V2_LINE_FLAG_INPUT | \
+GPIO_V2_LINE_FLAG_OUTPUT)
+
+#define GPIO_V2_LINE_DRIVE_FLAGS \
+ (GPIO_V2_LINE_FLAG_OPEN_DRAIN | \
+GPIO_V2_LINE_FLAG_OPEN_SOURCE)
+
+#define GPIO_V2_LINE_VALID_FLAGS \
+ (GPIO_V2_LINE_FLAG_ACTIVE_LOW | \
+GPIO_V2_LINE_DIRECTION_FLAGS | \
+GPIO_V2_LINE_DRIVE_FLAGS | \
+GPIO_V2_LINE_BIAS_FLAGS)
+
+static u64 gpio_v2_line_config_flags(struct gpio_v2_line_config *lc,
+int line_idx)
+{
+ int i;
+ u64 mask = BIT_ULL(line_idx);
+
+ for (i = 0; i < lc->num_attrs; i++) {
+ if ((lc->attrs[i].attr.id == GPIO_V2_LINE_ATTR_ID_FLAGS) &&
+ (lc->attrs[i].mask & mask))
+ return lc->attrs[i].attr.flags;
+ }
+ return lc->flags;
+}
+
+static int gpio_v2_line_config_output_value(struct gpio_v2_line_config *lc,
+ int line_idx)
+{
+ int i;
+ u64 mask = BIT_ULL(line_idx);
+
+ for (i = 0; i < lc->num_attrs; i++) {
+ if ((lc->attrs[i].attr.id ==
GPIO_V2_LINE_ATTR_ID_OUTPUT_VALUES) &&
+ (lc->attrs[i].mask & mask))
+ return !!(lc->attrs[i].attr.values & mask);
+ }
+ return 0;
+}
+
+static int gpio_v2_line_flags_validate(u64 flags)
+{
+ /* Return an error if an unknown flag is set */
+ if (flags & ~GPIO_V2_LINE_VALID_FLAGS)
+ return -EINVAL;
+
+ /*
+* Do not allow both INPUT & OUTPUT flags to be set as they are
+* contradictory.
+*/
+ if ((flags & GPIO_V2_LINE_FLAG_INPUT) &&
+ (flags & GPIO_V2_LINE_FLAG_OUTPUT))
+ return -EINVAL;
+
+ /*
+* Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If
+* the hardware actually supports enabling both at the same time the
+* electrical result would be disastrous.
+*/
+ if ((flags & GPIO_V2_LINE_FLAG_OPEN_DRAIN) &&
+ (flags & GPIO_V2_LINE_FLAG_OPEN_SOURCE))
+ return -EINVAL;
+
+ /* Drive requires explicit output direction. */
+ if ((flags & GPIO_V2_LINE_DRIVE_FLAGS) &&
+ !(flags & GPIO_V2_LINE_FLAG_OUTPUT))
+ return -EINVAL;
+
+ /* Bias requies explicit direction. */
+ if ((flags & GPIO_V2_LINE_BIAS_FLAGS) &&
+ !(flags & GPIO_V2_LINE_DIRECTION_FLAGS))
+ return -EINVAL;
+
+ /* Only one bias flag can be set. */
+ if (((flags & GPIO_V2_LINE_FLAG_BIAS_DISABLED) &&
+(flags & (GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN |
+ GPIO_V2_LINE_FLAG_BIAS_PULL_UP))) ||
+ ((flags & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN) &&
+(flags & GPIO_V2_LINE_FLAG_BIAS_PULL_UP)))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int gpio_v2_line_config_validate(struct gpio_v2_line_config *lc,
+ int num_lines)
+{
+ int i, ret;
+ u64 flags;
+
+ if (lc->num_attrs >
[PATCH v3 00/18] gpio: cdev: add uAPI v2
This patchset defines and implements adds a new version of the GPIO CDEV uAPI to address existing 32/64-bit alignment issues, add support for debounce, event sequence numbers, and allowing for requested lines with different configurations. It provides some future proofing by adding optional configuration fields and padding reserved for future use. The series can be partitioned into two sets; the first eleven contain the v2 uAPI implementation, and the final seven port the GPIO tools to the v2 uAPI and extend them to use new uAPI features. The more complicated patches include their own commentary where appropriate. Cheers, Kent. Changes since v2: - disabling the character device from the build requires EXPERT - uAPI revisions (see patch 02) - replace padding_not_zeroed with calls to memchr_inv - don't use bitops on 64-bit flags as that doesn't work on BE-32 - accept first attribute matching a line in gpio_v2_line_config.attrs rather than the last - rework lsgpio port to uAPI v2 as flags reverted to v1 like layout (since patch v2) - swapped patches 17 and 18 to apply debounce to multiple monitored lines Changes since v1: - split out cleanup patches into a separate series. - split implementation patch into a patch for each ioctl or major feature. - split tool port patch into a patch per tool. - rework uAPI to allow requested lines with different configurations. Kent Gibson (18): gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes gpio: uapi: define uAPI v2 gpiolib: make cdev a build option gpiolib: add build option for CDEV v1 ABI gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL gpiolib: cdev: support edge detection for uAPI v2 gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL gpiolib: cdev: support setting debounce gpio: uapi: document uAPI v1 as deprecated tools: gpio: port lsgpio to v2 uAPI tools: gpio: port gpio-watch to v2 uAPI tools: gpio: rename nlines to num_lines tools: gpio: port gpio-hammer to v2 uAPI tools: gpio: port gpio-event-mon to v2 uAPI tools: gpio: add multi-line monitoring to gpio-event-mon tools: gpio: add debounce support to gpio-event-mon drivers/gpio/Kconfig| 29 +- drivers/gpio/Makefile |2 +- drivers/gpio/gpiolib-cdev.c | 1333 ++- drivers/gpio/gpiolib-cdev.h | 15 + drivers/gpio/gpiolib.c |2 + drivers/gpio/gpiolib.h |6 + include/uapi/linux/gpio.h | 315 - tools/gpio/gpio-event-mon.c | 146 ++-- tools/gpio/gpio-hammer.c| 56 +- tools/gpio/gpio-utils.c | 127 ++-- tools/gpio/gpio-utils.h | 50 +- tools/gpio/gpio-watch.c | 16 +- tools/gpio/lsgpio.c | 60 +- 13 files changed, 1943 insertions(+), 214 deletions(-) base-commit: 22cc422070d9a9a399f8a70b89f1b852945444cb -- 2.28.0
[PATCH v3 06/18] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL
Add support for GPIO_V2_GET_LINEINFO_IOCTL and
GPIO_V2_GET_LINEINFO_WATCH_IOCTL.
Signed-off-by: Kent Gibson
---
The core of this change is the event kfifo switching to contain
struct gpioline_info_changed_v2, instead of v1 as v2 is richer.
The two uAPI versions are mostly independent - other than where they both
provide line info changes via reads on the chip fd. As the info change
structs differ between v1 and v2, the infowatch implementation tracks which
version of the infowatch ioctl, either GPIO_GET_LINEINFO_WATCH_IOCTL or
GPIO_V2_GET_LINEINFO_WATCH_IOCTL, initiates the initial watch and returns
the corresponding info change struct to the read. The version supported
on that fd locks to that version on the first watch request, so subsequent
watches from that process must use the same uAPI version.
drivers/gpio/gpiolib-cdev.c | 196 +++-
1 file changed, 169 insertions(+), 27 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 4b657492d836..f88e012984d9 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -162,7 +162,8 @@ static long linehandle_set_config(struct linehandle_state
*lh,
}
blocking_notifier_call_chain(>gdev->notifier,
-GPIOLINE_CHANGED_CONFIG, desc);
+GPIO_V2_LINE_CHANGED_CONFIG,
+desc);
}
return 0;
}
@@ -334,7 +335,7 @@ static int linehandle_create(struct gpio_device *gdev, void
__user *ip)
}
blocking_notifier_call_chain(>gdev->notifier,
-GPIOLINE_CHANGED_REQUESTED, desc);
+GPIO_V2_LINE_CHANGED_REQUESTED,
desc);
dev_dbg(>dev, "registered chardev handle for line %d\n",
offset);
@@ -716,7 +717,7 @@ static int line_create(struct gpio_device *gdev, void
__user *ip)
}
blocking_notifier_call_chain(>gdev->notifier,
-GPIOLINE_CHANGED_REQUESTED, desc);
+GPIO_V2_LINE_CHANGED_REQUESTED,
desc);
dev_dbg(>dev, "registered chardev handle for line %d\n",
offset);
@@ -1065,7 +1066,7 @@ static int lineevent_create(struct gpio_device *gdev,
void __user *ip)
goto out_free_le;
blocking_notifier_call_chain(>gdev->notifier,
-GPIOLINE_CHANGED_REQUESTED, desc);
+GPIO_V2_LINE_CHANGED_REQUESTED, desc);
irq = gpiod_to_irq(desc);
if (irq <= 0) {
@@ -1132,10 +1133,52 @@ static int lineevent_create(struct gpio_device *gdev,
void __user *ip)
return ret;
}
+static void gpio_v2_line_info_to_v1(struct gpio_v2_line_info *info_v2,
+ struct gpioline_info *info_v1)
+{
+ int flagsv2 = info_v2->flags;
+
+ strncpy(info_v1->name, info_v2->name, sizeof(info_v1->name));
+ strncpy(info_v1->consumer, info_v2->consumer,
+ sizeof(info_v1->consumer));
+ info_v1->line_offset = info_v2->offset;
+ info_v1->flags = 0;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_USED)
+ info_v1->flags |= GPIOLINE_FLAG_KERNEL;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_OUTPUT)
+ info_v1->flags |= GPIOLINE_FLAG_IS_OUT;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_ACTIVE_LOW)
+ info_v1->flags |= GPIOLINE_FLAG_ACTIVE_LOW;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_OPEN_DRAIN)
+ info_v1->flags |= GPIOLINE_FLAG_OPEN_DRAIN;
+ if (flagsv2 & GPIO_V2_LINE_FLAG_OPEN_SOURCE)
+ info_v1->flags |= GPIOLINE_FLAG_OPEN_SOURCE;
+
+ if (flagsv2 & GPIO_V2_LINE_FLAG_BIAS_PULL_UP)
+ info_v1->flags |= GPIOLINE_FLAG_BIAS_PULL_UP;
+ if (flagsv2 & GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN)
+ info_v1->flags |= GPIOLINE_FLAG_BIAS_PULL_DOWN;
+ if (flagsv2 & GPIO_V2_LINE_FLAG_BIAS_DISABLED)
+ info_v1->flags |= GPIOLINE_FLAG_BIAS_DISABLE;
+}
+
+static void gpio_v2_line_info_changed_to_v1(
+ struct gpio_v2_line_info_changed *lic_v2,
+ struct gpioline_info_changed *lic_v1)
+{
+ gpio_v2_line_info_to_v1(_v2->info, _v1->info);
+ lic_v1->timestamp = lic_v2->timestamp;
+ lic_v1->event_type = lic_v2->event_type;
+}
+
#endif /* CONFIG_GPIO_CDEV_V1 */
static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
- struct gpioline_info *info)
+ struct gpio_v2_line_info *info)
{
struct gpio_chip *gc = desc->gdev->chip;
bool ok_for_pinctrl;
@@ -1149,7 +1192,7 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc,
* lock common to both
[PATCH v3 01/18] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes
Replace constant array sizes with a macro constant to clarify the source
of array sizes, provide a place to document any constraints on the size,
and to simplify array sizing in userspace if constructing structs
from their composite fields.
Signed-off-by: Kent Gibson
---
include/uapi/linux/gpio.h | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 9c27cecf406f..285cc10355b2 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -14,6 +14,11 @@
#include
#include
+/*
+ * The maximum size of name and label arrays.
+ */
+#define GPIO_MAX_NAME_SIZE 32
+
/**
* struct gpiochip_info - Information about a certain GPIO chip
* @name: the Linux kernel name of this GPIO chip
@@ -22,8 +27,8 @@
* @lines: number of GPIO lines on this chip
*/
struct gpiochip_info {
- char name[32];
- char label[32];
+ char name[GPIO_MAX_NAME_SIZE];
+ char label[GPIO_MAX_NAME_SIZE];
__u32 lines;
};
@@ -52,8 +57,8 @@ struct gpiochip_info {
struct gpioline_info {
__u32 line_offset;
__u32 flags;
- char name[32];
- char consumer[32];
+ char name[GPIO_MAX_NAME_SIZE];
+ char consumer[GPIO_MAX_NAME_SIZE];
};
/* Maximum number of requested handles */
@@ -123,7 +128,7 @@ struct gpiohandle_request {
__u32 lineoffsets[GPIOHANDLES_MAX];
__u32 flags;
__u8 default_values[GPIOHANDLES_MAX];
- char consumer_label[32];
+ char consumer_label[GPIO_MAX_NAME_SIZE];
__u32 lines;
int fd;
};
@@ -182,7 +187,7 @@ struct gpioevent_request {
__u32 lineoffset;
__u32 handleflags;
__u32 eventflags;
- char consumer_label[32];
+ char consumer_label[GPIO_MAX_NAME_SIZE];
int fd;
};
--
2.28.0
[PATCH v3 03/18] gpiolib: make cdev a build option
Make the gpiolib-cdev module a build option. This allows the CDEV
interface to be removed from the kernel to reduce kernel size in
applications where is it not required, and provides the parent for
other other CDEV interface specific build options to follow.
Suggested-by: Bartosz Golaszewski
Signed-off-by: Kent Gibson
---
drivers/gpio/Kconfig| 17 +++--
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpiolib-cdev.h | 15 +++
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8030fd91a3cc..8e409b9c33dc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -66,8 +66,21 @@ config GPIO_SYSFS
This ABI is deprecated. If you want to use GPIO from userspace,
use the character device /dev/gpiochipN with the appropriate
- ioctl() operations instead. The character device is always
- available.
+ ioctl() operations instead.
+
+config GPIO_CDEV
+ bool
+ prompt "Character device (/dev/gpiochipN) support" if EXPERT
+ default y
+ help
+ Say Y here to add the character device /dev/gpiochipN interface
+ for GPIOs. The character device allows userspace to control GPIOs
+ using ioctl() operations.
+
+ Only say N if you are sure that the GPIO character device is not
+ required.
+
+ If unsure, say Y.
config GPIO_GENERIC
depends on HAS_IOMEM # Only for IOMEM drivers
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4f9abff4f2dc..7c24c8d77068 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -7,8 +7,8 @@ obj-$(CONFIG_GPIOLIB) += gpiolib.o
obj-$(CONFIG_GPIOLIB) += gpiolib-devres.o
obj-$(CONFIG_GPIOLIB) += gpiolib-legacy.o
obj-$(CONFIG_GPIOLIB) += gpiolib-devprop.o
-obj-$(CONFIG_GPIOLIB) += gpiolib-cdev.o
obj-$(CONFIG_OF_GPIO) += gpiolib-of.o
+obj-$(CONFIG_GPIO_CDEV)+= gpiolib-cdev.o
obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
diff --git a/drivers/gpio/gpiolib-cdev.h b/drivers/gpio/gpiolib-cdev.h
index 973578e7ad10..19a4e3d57120 100644
--- a/drivers/gpio/gpiolib-cdev.h
+++ b/drivers/gpio/gpiolib-cdev.h
@@ -5,7 +5,22 @@
#include
+#ifdef CONFIG_GPIO_CDEV
+
int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt);
void gpiolib_cdev_unregister(struct gpio_device *gdev);
+#else
+
+static inline int gpiolib_cdev_register(struct gpio_device *gdev, dev_t devt)
+{
+ return 0;
+}
+
+static inline void gpiolib_cdev_unregister(struct gpio_device *gdev)
+{
+}
+
+#endif /* CONFIG_GPIO_CDEV */
+
#endif /* GPIOLIB_CDEV_H */
--
2.28.0
[PATCH v3 10/18] gpiolib: cdev: support setting debounce
Add support for setting debounce on a line via the GPIO uAPI.
Where debounce is not supported by hardware, a software debounce is
provided.
Signed-off-by: Kent Gibson
---
The implementation of the software debouncer waits for the line to be
stable for the debounce period before determining if a level change,
and a corresponding edge event, has occurred. This provides maximum
protection against glitches, but also introduces a debounce_period
latency to edge events.
The software debouncer is integrated with the edge detection as it
utilises the line interrupt, and integration is simpler than getting
the two to interwork. Where software debounce AND edge detection is
required, the debouncer provides both.
Due to the tight integration between the debouncer and edge detection,
and to avoid particular corner cases, it is not allowed to alter the
debounce value if edge detection is enabled. Changing the debounce with
edge detection enabled is a very unlikely use case, so it is preferable
to disallow it rather than complicate the code to allow it.
Should the user wish to alter the debounce value in such cases they will
need to release and re-request the line.
Changes since v2:
- only GPIO_V2 field renaming
Changes since v1:
- improve documentation on fields shared by threads.
- use READ_ONCE/WRITE_ONCE for shared fields rather than atomic_t
which was overkill.
drivers/gpio/gpiolib-cdev.c | 265 +++-
drivers/gpio/gpiolib.h | 4 +
2 files changed, 263 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 2f5cc835133c..8884478d1535 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
#include
#include
#include
+#include
#include
#include "gpiolib.h"
@@ -395,6 +397,9 @@ static int linehandle_create(struct gpio_device *gdev, void
__user *ip)
* for the corresponding line request. Ths is drawn from the @line.
* @line_seqno: the seqno for the current edge event in the sequence of
* events for this line.
+ * @work: the worker that implements software debouncing
+ * @sw_debounced: flag indicating if the software debouncer is active
+ * @level: the current debounced physical level of the line
*/
struct edge_detector {
struct line *line;
@@ -406,7 +411,27 @@ struct edge_detector {
*/
u64 timestamp;
u32 seqno;
+ /*
+* line_seqno is used by either edge_irq_thread() or
+* debounce_work_func() which are themselves mutually exclusive.
+*/
u32 line_seqno;
+ /*
+* -- debouncer specific fields --
+*/
+ struct delayed_work work;
+ /*
+* sw_debounce is shared by line_set_config(), which is the only
+* setter, and line_ioctl(), which can live with a slightly stale
+* value.
+*/
+ unsigned int sw_debounced;
+ /*
+* level is shared by debounce_work_func(), which is the only
+* setter, and line_ioctl() which can live with a slightly stale
+* value.
+*/
+ unsigned int level;
};
/**
@@ -523,6 +548,10 @@ static int edge_detector_start(struct edge_detector *edet)
int ret, irq, irqflags = 0;
struct gpio_desc *desc;
+ if (READ_ONCE(edet->sw_debounced))
+ /* debouncer is setup and will provide edge detection */
+ return 0;
+
desc = edge_detector_desc(edet);
irq = gpiod_to_irq(desc);
@@ -554,17 +583,215 @@ static int edge_detector_start(struct edge_detector
*edet)
return 0;
}
+/*
+ * returns the current debounced logical value.
+ */
+static int debounced_value(struct edge_detector *edet)
+{
+ int value;
+
+ /*
+* minor race - debouncer may be stopped here, so edge_detector_stop
+* must leave the value unchanged so the following will read the level
+* from when the debouncer was last running.
+*/
+ value = READ_ONCE(edet->level);
+
+ if (test_bit(FLAG_ACTIVE_LOW, _detector_desc(edet)->flags))
+ value = !value;
+
+ return value;
+}
+
+static irqreturn_t debounce_irq_handler(int irq, void *p)
+{
+ struct edge_detector *edet = p;
+ struct gpio_desc *desc = edge_detector_desc(edet);
+
+ mod_delayed_work(system_wq,
+>work,
+usecs_to_jiffies(READ_ONCE(desc->debounce_period)));
+
+ return IRQ_HANDLED;
+}
+
+static void debounce_work_func(struct work_struct *work)
+{
+ struct gpio_v2_line_event le;
+ int ret, level;
+ struct edge_detector *edet =
+ container_of(work, struct edge_detector, work.work);
+ struct gpio_desc *desc = edge_detector_desc(edet);
+ struct line *line;
+
+ level = gpiod_get_raw_value_cansleep(desc);
+ if
[PATCH v3 11/18] gpio: uapi: document uAPI v1 as deprecated
Update uAPI documentation to deprecate v1 structs and ioctls.
Signed-off-by: Kent Gibson
---
include/uapi/linux/gpio.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h
index 82e8744b8c3b..286f5522378c 100644
--- a/include/uapi/linux/gpio.h
+++ b/include/uapi/linux/gpio.h
@@ -273,6 +273,9 @@ struct gpio_v2_line_event {
/*
* ABI v1
+ *
+ * This version of the ABI is deprecated and will be removed in the future.
+ * Use the latest version of the ABI, defined above, instead.
*/
/* Informational flags */
@@ -296,6 +299,9 @@ struct gpio_v2_line_event {
* @consumer: a functional name for the consumer of this GPIO line as set by
* whatever is using it, will be empty if there is no current user but may
* also be empty if the consumer doesn't set this up
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_info instead.
*/
struct gpioline_info {
__u32 line_offset;
@@ -327,6 +333,9 @@ enum {
* guarantee there are no implicit holes between it and subsequent members.
* The 20-byte padding at the end makes sure we don't add any implicit padding
* at the end of the structure on 64-bit architectures.
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_info_changed instead.
*/
struct gpioline_info_changed {
struct gpioline_info info;
@@ -366,6 +375,9 @@ struct gpioline_info_changed {
* @fd: if successful this field will contain a valid anonymous file handle
* after a GPIO_GET_LINEHANDLE_IOCTL operation, zero or negative value
* means error
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_request instead.
*/
struct gpiohandle_request {
__u32 lineoffsets[GPIOHANDLES_MAX];
@@ -385,6 +397,9 @@ struct gpiohandle_request {
* this specifies the default output value, should be 0 (low) or
* 1 (high), anything else than 0 or 1 will be interpreted as 1 (high)
* @padding: reserved for future use and should be zero filled
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_config instead.
*/
struct gpiohandle_config {
__u32 flags;
@@ -397,6 +412,9 @@ struct gpiohandle_config {
* @values: when getting the state of lines this contains the current
* state of a line, when setting the state of lines these should contain
* the desired target state
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_values instead.
*/
struct gpiohandle_data {
__u8 values[GPIOHANDLES_MAX];
@@ -420,6 +438,9 @@ struct gpiohandle_data {
* @fd: if successful this field will contain a valid anonymous file handle
* after a GPIO_GET_LINEEVENT_IOCTL operation, zero or negative value
* means error
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_request instead.
*/
struct gpioevent_request {
__u32 lineoffset;
@@ -439,6 +460,9 @@ struct gpioevent_request {
* struct gpioevent_data - The actual event being pushed to userspace
* @timestamp: best estimate of time of event occurrence, in nanoseconds
* @id: event identifier
+ *
+ * This struct is part of ABI v1 and is deprecated.
+ * Use struct gpio_v2_line_event instead.
*/
struct gpioevent_data {
__u64 timestamp;
@@ -463,6 +487,8 @@ struct gpioevent_data {
/*
* v1 ioctl()s
+ *
+ * These ioctl()s are deprecated. Use the v2 equivalent instead.
*/
#define GPIO_GET_LINEINFO_IOCTL _IOWR(0xB4, 0x02, struct gpioline_info)
#define GPIO_GET_LINEHANDLE_IOCTL _IOWR(0xB4, 0x03, struct gpiohandle_request)
--
2.28.0
[PATCH v3 07/18] gpiolib: cdev: support edge detection for uAPI v2
Add support for edge detection to lines requested using
GPIO_V2_GET_LINE_IOCTL.
Signed-off-by: Kent Gibson
---
The edge_detector implementation is based on the v1 lineevent implementation.
drivers/gpio/gpiolib-cdev.c | 316 +++-
drivers/gpio/gpiolib.c | 2 +
drivers/gpio/gpiolib.h | 2 +
3 files changed, 319 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index f88e012984d9..c1b916224240 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -382,11 +382,43 @@ static int linehandle_create(struct gpio_device *gdev,
void __user *ip)
}
#endif /* CONFIG_GPIO_CDEV_V1 */
+/**
+ * struct edge_detector - contains the state of a line edge detector
+ * @line: the corresponding line request
+ * @irq: the interrupt triggered in response to events on this GPIO
+ * @flags: the flags, GPIO_V2_LINE_FLAG_EDGE_RISING and/or
+ * GPIO_V2_LINE_FLAG_EDGE_FALLING, indicating the edge detection applied
+ * @timestamp: cache for the timestamp storing it between hardirq and IRQ
+ * thread, used to bring the timestamp close to the actual event
+ * @seqno: the seqno for the current edge event in the sequence of events
+ * for the corresponding line request. Ths is drawn from the @line.
+ * @line_seqno: the seqno for the current edge event in the sequence of
+ * events for this line.
+ */
+struct edge_detector {
+ struct line *line;
+ unsigned int irq;
+ u64 flags;
+ /*
+* timestamp and seqno are shared by edge_irq_handler() and
+* edge_irq_thread() which are themselves mutually exclusive.
+*/
+ u64 timestamp;
+ u32 seqno;
+ u32 line_seqno;
+};
+
/**
* struct line - contains the state of a userspace line request
* @gdev: the GPIO device the line request pertains to
* @label: consumer label used to tag descriptors
* @num_descs: the number of descriptors held in the descs array
+ * @wait: wait queue that handles blocking reads of events
+ * @events: KFIFO for the GPIO events
+ * @seqno: the sequence number for edge events generated on all lines in
+ * this line request. Note that this is not used when @num_descs is 1, as
+ * the line_seqno is then the same and is cheaper to calculate.
+ * @edets: an array of edge detectors, of size @num_descs
* @descs: the GPIO descriptors held by this line request, with @num_descs
* elements.
*/
@@ -394,9 +426,146 @@ struct line {
struct gpio_device *gdev;
const char *label;
u32 num_descs;
+ wait_queue_head_t wait;
+ DECLARE_KFIFO_PTR(events, struct gpio_v2_line_event);
+ atomic_t seqno;
+ struct edge_detector *edets;
struct gpio_desc *descs[];
};
+static inline struct gpio_desc *edge_detector_desc(
+ const struct edge_detector *edet)
+{
+ return edet->line->descs[edet - >line->edets[0]];
+}
+
+static irqreturn_t edge_irq_thread(int irq, void *p)
+{
+ struct edge_detector *edet = p;
+ struct line *line = edet->line;
+ struct gpio_desc *desc = edge_detector_desc(edet);
+ struct gpio_v2_line_event le;
+ int ret;
+
+ /* Do not leak kernel stack to userspace */
+ memset(, 0, sizeof(le));
+
+ /*
+* We may be running from a nested threaded interrupt in which case
+* we didn't get the timestamp from edge_irq_handler().
+*/
+ if (!edet->timestamp) {
+ le.timestamp = ktime_get_ns();
+ if (line->num_descs != 1)
+ edet->seqno = atomic_inc_return(>seqno);
+ } else {
+ le.timestamp = edet->timestamp;
+ }
+ edet->timestamp = 0;
+
+ if (edet->flags == (GPIO_V2_LINE_FLAG_EDGE_RISING |
+ GPIO_V2_LINE_FLAG_EDGE_FALLING)) {
+ int level = gpiod_get_value_cansleep(desc);
+
+ if (level)
+ /* Emit low-to-high event */
+ le.id = GPIO_V2_LINE_EVENT_RISING_EDGE;
+ else
+ /* Emit high-to-low event */
+ le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE;
+ } else if (edet->flags == GPIO_V2_LINE_FLAG_EDGE_RISING) {
+ /* Emit low-to-high event */
+ le.id = GPIO_V2_LINE_EVENT_RISING_EDGE;
+ } else if (edet->flags == GPIO_V2_LINE_FLAG_EDGE_FALLING) {
+ /* Emit high-to-low event */
+ le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE;
+ } else {
+ return IRQ_NONE;
+ }
+ edet->line_seqno++;
+ le.line_seqno = edet->line_seqno;
+ le.seqno = (line->num_descs == 1) ? le.line_seqno : edet->seqno;
+ le.offset = gpio_chip_hwgpio(desc);
+
+ ret = kfifo_in_spinlocked_noirqsave(>events, ,
+ 1, >wait.lock);
+ if (ret)
+ wake_up_poll(>wait, EPOLLIN);
+ else
+
[PATCH v3 12/18] tools: gpio: port lsgpio to v2 uAPI
Port the lsgpio tool to the latest GPIO uAPI.
Signed-off-by: Kent Gibson
---
tools/gpio/lsgpio.c | 60 -
1 file changed, 38 insertions(+), 22 deletions(-)
diff --git a/tools/gpio/lsgpio.c b/tools/gpio/lsgpio.c
index b08d7a5e779b..deda38244026 100644
--- a/tools/gpio/lsgpio.c
+++ b/tools/gpio/lsgpio.c
@@ -25,57 +25,73 @@
struct gpio_flag {
char *name;
- unsigned long mask;
+ unsigned long long mask;
};
struct gpio_flag flagnames[] = {
{
- .name = "kernel",
- .mask = GPIOLINE_FLAG_KERNEL,
+ .name = "used",
+ .mask = GPIO_V2_LINE_FLAG_USED,
+ },
+ {
+ .name = "input",
+ .mask = GPIO_V2_LINE_FLAG_INPUT,
},
{
.name = "output",
- .mask = GPIOLINE_FLAG_IS_OUT,
+ .mask = GPIO_V2_LINE_FLAG_OUTPUT,
},
{
.name = "active-low",
- .mask = GPIOLINE_FLAG_ACTIVE_LOW,
+ .mask = GPIO_V2_LINE_FLAG_ACTIVE_LOW,
},
{
.name = "open-drain",
- .mask = GPIOLINE_FLAG_OPEN_DRAIN,
+ .mask = GPIO_V2_LINE_FLAG_OPEN_DRAIN,
},
{
.name = "open-source",
- .mask = GPIOLINE_FLAG_OPEN_SOURCE,
+ .mask = GPIO_V2_LINE_FLAG_OPEN_SOURCE,
},
{
.name = "pull-up",
- .mask = GPIOLINE_FLAG_BIAS_PULL_UP,
+ .mask = GPIO_V2_LINE_FLAG_BIAS_PULL_UP,
},
{
.name = "pull-down",
- .mask = GPIOLINE_FLAG_BIAS_PULL_DOWN,
+ .mask = GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN,
},
{
.name = "bias-disabled",
- .mask = GPIOLINE_FLAG_BIAS_DISABLE,
+ .mask = GPIO_V2_LINE_FLAG_BIAS_DISABLED,
},
};
-void print_flags(unsigned long flags)
+static void print_attributes(struct gpio_v2_line_info *info)
{
int i;
- int printed = 0;
+ const char *field_format = "%s";
for (i = 0; i < ARRAY_SIZE(flagnames); i++) {
- if (flags & flagnames[i].mask) {
- if (printed)
- fprintf(stdout, " ");
- fprintf(stdout, "%s", flagnames[i].name);
- printed++;
+ if (info->flags & flagnames[i].mask) {
+ fprintf(stdout, field_format, flagnames[i].name);
+ field_format = ", %s";
}
}
+
+ if ((info->flags & GPIO_V2_LINE_FLAG_EDGE_RISING) &&
+ (info->flags & GPIO_V2_LINE_FLAG_EDGE_FALLING))
+ fprintf(stdout, field_format, "both-edges");
+ else if (info->flags & GPIO_V2_LINE_FLAG_EDGE_RISING)
+ fprintf(stdout, field_format, "rising-edge");
+ else if (info->flags & GPIO_V2_LINE_FLAG_EDGE_FALLING)
+ fprintf(stdout, field_format, "falling-edge");
+
+ for (i = 0; i < info->num_attrs; i++) {
+ if (info->attrs[i].id == GPIO_V2_LINE_ATTR_ID_DEBOUNCE)
+ fprintf(stdout, ", debounce_period=%dusec",
+ info->attrs[0].debounce_period);
+ }
}
int list_device(const char *device_name)
@@ -109,18 +125,18 @@ int list_device(const char *device_name)
/* Loop over the lines and print info */
for (i = 0; i < cinfo.lines; i++) {
- struct gpioline_info linfo;
+ struct gpio_v2_line_info linfo;
memset(, 0, sizeof(linfo));
- linfo.line_offset = i;
+ linfo.offset = i;
- ret = ioctl(fd, GPIO_GET_LINEINFO_IOCTL, );
+ ret = ioctl(fd, GPIO_V2_GET_LINEINFO_IOCTL, );
if (ret == -1) {
ret = -errno;
perror("Failed to issue LINEINFO IOCTL\n");
goto exit_close_error;
}
- fprintf(stdout, "\tline %2d:", linfo.line_offset);
+ fprintf(stdout, "\tline %2d:", linfo.offset);
if (linfo.name[0])
fprintf(stdout, " \"%s\"", linfo.name);
else
@@ -131,7 +147,7 @@ int list_device(const char *device_name)
fprintf(stdout, " unused");
if (linfo.flags) {
fprintf(stdout, " [");
- print_flags(linfo.flags);
+ print_attributes();
fprintf(stdout, "]");
}
fprintf(stdout, "\n");
--
2.28.0
[PATCH v3 14/18] tools: gpio: rename nlines to num_lines
Rename nlines to num_lines to be consistent with other usage for fields
describing the number of entries in an array.
Signed-off-by: Kent Gibson
---
tools/gpio/gpio-hammer.c | 26 +-
tools/gpio/gpio-utils.c | 20 ++--
tools/gpio/gpio-utils.h | 6 +++---
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/tools/gpio/gpio-hammer.c b/tools/gpio/gpio-hammer.c
index 9fd926e8cb52..a2c7577fad5c 100644
--- a/tools/gpio/gpio-hammer.c
+++ b/tools/gpio/gpio-hammer.c
@@ -22,7 +22,7 @@
#include
#include "gpio-utils.h"
-int hammer_device(const char *device_name, unsigned int *lines, int nlines,
+int hammer_device(const char *device_name, unsigned int *lines, int num_lines,
unsigned int loops)
{
struct gpiohandle_data data;
@@ -33,7 +33,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
unsigned int iteration = 0;
memset(, 0, sizeof(data.values));
- ret = gpiotools_request_linehandle(device_name, lines, nlines,
+ ret = gpiotools_request_linehandle(device_name, lines, num_lines,
GPIOHANDLE_REQUEST_OUTPUT, ,
"gpio-hammer");
if (ret < 0)
@@ -46,15 +46,15 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
goto exit_close_error;
fprintf(stdout, "Hammer lines [");
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d", lines[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "] on %s, initial states: [", device_name);
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d", data.values[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "]\n");
@@ -63,7 +63,7 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
j = 0;
while (1) {
/* Invert all lines so we blink */
- for (i = 0; i < nlines; i++)
+ for (i = 0; i < num_lines; i++)
data.values[i] = !data.values[i];
ret = gpiotools_set_values(fd, );
@@ -81,9 +81,9 @@ int hammer_device(const char *device_name, unsigned int
*lines, int nlines,
j = 0;
fprintf(stdout, "[");
- for (i = 0; i < nlines; i++) {
+ for (i = 0; i < num_lines; i++) {
fprintf(stdout, "%d: %d", lines[i], data.values[i]);
- if (i != (nlines - 1))
+ if (i != (num_lines - 1))
fprintf(stdout, ", ");
}
fprintf(stdout, "]\r");
@@ -121,7 +121,7 @@ int main(int argc, char **argv)
const char *device_name = NULL;
unsigned int lines[GPIOHANDLES_MAX];
unsigned int loops = 0;
- int nlines;
+ int num_lines;
int c;
int i;
@@ -158,11 +158,11 @@ int main(int argc, char **argv)
return -1;
}
- nlines = i;
+ num_lines = i;
- if (!device_name || !nlines) {
+ if (!device_name || !num_lines) {
print_usage();
return -1;
}
- return hammer_device(device_name, lines, nlines, loops);
+ return hammer_device(device_name, lines, num_lines, loops);
}
diff --git a/tools/gpio/gpio-utils.c b/tools/gpio/gpio-utils.c
index 16a5d9cb9da2..d527980bcb94 100644
--- a/tools/gpio/gpio-utils.c
+++ b/tools/gpio/gpio-utils.c
@@ -38,7 +38,7 @@
* such as "gpiochip0"
* @lines: An array desired lines, specified by offset
* index for the associated GPIO device.
- * @nline: The number of lines to request.
+ * @num_lines: The number of lines to request.
* @flag: The new flag for requsted gpio. Reference
* "linux/gpio.h" for the meaning of flag.
* @data: Default value will be set to gpio when flag is
@@ -56,7 +56,7 @@
* On failure return the errno.
*/
int gpiotools_request_linehandle(const char *device_name, unsigned int *lines,
-unsigned int nlines, unsigned int flag,
+unsigned int num_lines, unsigned int flag,
struct gpiohandle_data *data,
const char *consumer_label)
{
@@ -78,12 +78,12 @@ int gpiotools_request_linehandle(const char *device_name,
unsigned int *lines,
goto exit_free_name;
}
- for (i = 0; i < nlines; i++)
+
