[PATCH v2] Drivers: hv: vmbus: Expose counters for interrupts and full conditions
Counter values for per-channel interrupts and ring buffer full
conditions are useful for investigating performance.
Expose counters in sysfs for 2 types of guest to host interrupts:
1) Interrupts caused by the channel's outbound ring buffer transitioning
from empty to not empty
2) Interrupts caused by the channel's inbound ring buffer transitioning
from full to not full while a packet is waiting for enough buffer space to
become available
Expose 2 counters in sysfs for the number of times that write operations
encountered a full outbound ring buffer:
1) The total number of write operations that encountered a full
condition
2) The number of write operations that were the first to encounter a
full condition
I tested this patch by confirming that the sysfs files were created and
observing the counter values. The values seemed to increase by a
reasonable amount when the Hyper-v related drivers were in use.
Signed-off-by: Kimberly Brown
---
Changes in v2:
- Added mailing lists to the cc list
- Removed the host to guest interrupt counters proposed in v1 because
they were not accurate
- Added full condition counters for the channel's outbound ring buffer
Documentation/ABI/stable/sysfs-bus-vmbus | 33
drivers/hv/ring_buffer.c | 14 +-
drivers/hv/vmbus_drv.c | 32 +++
include/linux/hyperv.h | 32 +++
4 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus
b/Documentation/ABI/stable/sysfs-bus-vmbus
index 3fed8fdb873d..31dc89989032 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -146,3 +146,36 @@ KernelVersion: 4.16
Contact: Stephen Hemminger
Description: Binary file created by uio_hv_generic for ring buffer
Users: Userspace drivers
+
+What: /sys/bus/vmbus/devices//channels//intr_in_full
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Number of guest to host interrupts caused by the inbound ring
+ buffer transitioning from full to not full while a packet is
+ waiting for buffer space to become available
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//intr_out_empty
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Number of guest to host interrupts caused by the outbound ring
+ buffer transitioning from empty to not empty
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//out_full_first
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Number of write operations that were the first to encounter an
+ outbound ring buffer full condition
+Users: Debugging tools
+
+What: /sys/bus/vmbus/devices//channels//out_full_total
+Date: January 2019
+KernelVersion: 4.21
+Contact:Michael Kelley
+Description:Total number of write operations that encountered an outbound
+ ring buffer full condition
+Users: Debugging tools
diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index 64d0c85d5161..be2cbd0bea7d 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -74,8 +74,10 @@ static void hv_signal_on_write(u32 old_write, struct
vmbus_channel *channel)
* This is the only case we need to signal when the
* ring transitions from being empty to non-empty.
*/
- if (old_write == READ_ONCE(rbi->ring_buffer->read_index))
+ if (old_write == READ_ONCE(rbi->ring_buffer->read_index)) {
+ ++channel->intr_out_empty;
vmbus_setevent(channel);
+ }
}
/* Get the next write location for the specified ring buffer. */
@@ -273,10 +275,19 @@ int hv_ringbuffer_write(struct vmbus_channel *channel,
* is empty since the read index == write index.
*/
if (bytes_avail_towrite <= totalbytes_towrite) {
+ ++channel->out_full_total;
+
+ if (!channel->out_full_flag) {
+ ++channel->out_full_first;
+ channel->out_full_flag = true;
+ }
+
spin_unlock_irqrestore(&outring_info->ring_lock, flags);
return -EAGAIN;
}
+ channel->out_full_flag = false;
+
/* Write to the ring buffer */
next_write_location = hv_get_next_write_location(outring_info);
@@ -531,6 +542,7 @@ void hv_pkt_iter_close(struct vmbus_channel *channel)
if (curr_write_sz <= pending_sz)
return;
+ ++channel->intr_in_full;
vmbus_setevent(channel);
}
EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 283d184280af..460b7f
RE: [PATCH v3] staging: android: ion: Add implementation of dma_buf_vmap and dma_buf_vunmap
> -Original Message- > From: Liam Mark [mailto:lm...@codeaurora.org] > Sent: Friday, January 04, 2019 19:42 > To: Skidanov, Alexey > Cc: Laura Abbott ; Greg KH ; > de...@driverdev.osuosl.org; tk...@android.com; r...@android.com; linux- > ker...@vger.kernel.org; m...@android.com; sumit.sem...@linaro.org > Subject: Re: [PATCH v3] staging: android: ion: Add implementation of > dma_buf_vmap and > dma_buf_vunmap > > On Tue, 18 Dec 2018, Alexey Skidanov wrote: > > > >>> I was wondering if we could re-open the discussion on adding support to > > >>> ION for dma_buf_vmap. > > >>> It seems like the patch was not taken as the reviewers wanted more > > >>> evidence of an upstream use case. > > >>> > > >>> Here would be my upstream usage argument for including dma_buf_vmap > > >>> support in ION. > > >>> > > >>> Currently all calls to ion_dma_buf_begin_cpu_access result in the > > >>> creation > > >>> of a kernel mapping for the buffer, unfortunately the resulting call to > > >>> alloc_vmap_area can be quite expensive and this has caused a performance > > >>> regression for certain clients when they have moved to the new version > > >>> of > > >>> ION. > > >>> > > >>> The kernel mapping is not actually needed in > > >>> ion_dma_buf_begin_cpu_access, > > >>> and generally isn't needed by clients. So if we remove the creation of > > >>> the > > >>> kernel mapping in ion_dma_buf_begin_cpu_access and only create it when > > >>> needed we can speed up the calls to ion_dma_buf_begin_cpu_access. > > >>> > > >>> An additional benefit of removing the creation of kernel mappings from > > >>> ion_dma_buf_begin_cpu_access is that it makes the ION code more secure. > > >>> Currently a malicious client could call the DMA_BUF_IOCTL_SYNC IOCTL > > >>> with > > >>> flags DMA_BUF_SYNC_END multiple times to cause the ION buffer kmap_cnt > > >>> to > > >>> go negative which could lead to undesired behavior. > > >>> > > >>> One disadvantage of the above change is that a kernel mapping is not > > >>> already created when a client calls dma_buf_kmap. So the following > > >>> dma_buf_kmap contract can't be satisfied. > > >>> > > >>> /** > > >>> * dma_buf_kmap - Map a page of the buffer object into kernel address > > >>> space. The > > >>> * same restrictions as for kmap and friends apply. > > >>> * @dmabuf: [in]buffer to map page from. > > >>> * @page_num:[in]page in PAGE_SIZE units to map. > > >>> * > > >>> * This call must always succeed, any necessary preparations that might > > >>> fail > > >>> * need to be done in begin_cpu_access. > > >>> */ > > >>> > > >>> But hopefully we can work around this by moving clients to dma_buf_vmap. > > >> I think the problem is with the contract. We can't ensure that the call > > >> is always succeeds regardless the implementation - any mapping might > > >> fail. Probably this is why *all* clients of dma_buf_kmap() check the > > >> return value (so it's safe to return NULL in case of failure). > > >> > > > > > > I think currently the call to dma_buf_kmap will always succeed since the > > > DMA-Buf contract requires that the client first successfully call > > > dma_buf_begin_cpu_access(), and if dma_buf_begin_cpu_access() succeeds > > > then dma_buf_kmap will succeed. > > > > > >> I would suggest to fix the contract and to keep the dma_buf_kmap() > > >> support in ION. > > > > > > I will leave it to the DMA-Buf maintainers as to whether they want to > > > change their contract. > > > > > > Liam > > > > > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > > a Linux Foundation Collaborative Project > > > > > > > Ok. We need the list of the clients using the ION in the mainline tree. > > > > Looks to me like the only functions which might be calling > dma_buf_kmap/dma_buf_kunmap on ION buffers are > tegra_bo_kmap/tegra_bo_kunmap, I assume Tegra is used in some Android > automotive products. > > Looks like these functions could be moved over to using > dma_buf_vmap/dma_buf_vunmap but it wouldn't be very clean and would add a > performance hit. > > Liam > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project I'm a little bit confused. Why making the buffer accessible by CPU (mapping the buffer) and making the content of the buffer valid (coherent) are so tightly coupled in DMA-BUF? Alexey ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: mt7621-dma: Use struct_size() in devm_kzalloc()
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = devm_kzalloc(dev, sizeof(struct foo) + sizeof(void *) * count,
GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/staging/mt7621-dma/ralink-gdma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/mt7621-dma/ralink-gdma.c
b/drivers/staging/mt7621-dma/ralink-gdma.c
index 792a63bd55d4..d78042eba6dd 100644
--- a/drivers/staging/mt7621-dma/ralink-gdma.c
+++ b/drivers/staging/mt7621-dma/ralink-gdma.c
@@ -821,9 +821,9 @@ static int gdma_dma_probe(struct platform_device *pdev)
return -EINVAL;
data = (struct gdma_data *) match->data;
- dma_dev = devm_kzalloc(&pdev->dev, sizeof(*dma_dev) +
- (sizeof(struct gdma_dmaengine_chan) * data->chancnt),
- GFP_KERNEL);
+ dma_dev = devm_kzalloc(&pdev->dev,
+ struct_size(dma_dev, chan, data->chancnt),
+ GFP_KERNEL);
if (!dma_dev) {
dev_err(&pdev->dev, "alloc dma device failed\n");
return -EINVAL;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: fix typo
Fix spelling mistake: "lenghth" -> "length" Signed-off-by: Matteo Croce --- drivers/staging/comedi/drivers/usbduxfast.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/usbduxfast.c b/drivers/staging/comedi/drivers/usbduxfast.c index e18c0723b760..0d54f394dbd2 100644 --- a/drivers/staging/comedi/drivers/usbduxfast.c +++ b/drivers/staging/comedi/drivers/usbduxfast.c @@ -61,7 +61,7 @@ #define USBDUXFASTSUB_CPUCS0xE600 /* - * max lenghth of the transfer-buffer for software upload + * max length of the transfer-buffer for software upload */ #define TB_LEN 0x2000 -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: android: ion: Add chunk heaps instantiation
> -Original Message- > From: Laura Abbott [mailto:labb...@redhat.com] > Sent: Friday, January 04, 2019 03:58 > To: Skidanov, Alexey ; gre...@linuxfoundation.org; > Sumit > Semwal > Cc: de...@driverdev.osuosl.org > Subject: Re: [PATCH] staging: android: ion: Add chunk heaps instantiation > > On 1/2/19 10:28 PM, Alexey Skidanov wrote: > > > > > > On 1/3/19 12:37 AM, Laura Abbott wrote: > >> On 12/20/18 1:29 PM, Alexey Skidanov wrote: > >>> > >>> > >>> On 12/20/18 10:36 PM, Laura Abbott wrote: > On 12/16/18 2:46 AM, Alexey Skidanov wrote: > > Chunk heap instantiation should be supported for device tree platforms > > and > > non device tree platforms. For device tree platforms, it's a platform > > specific code responsibility to retrieve the heap configuration data > > and to call the appropriate API for heap creation. For non device tree > > platforms, there is no defined way to create the heaps. > > > > This patch provides the way of chunk heaps creation using > > "ion_chunk_heap=name:size@start" kernel boot parameter. > > > > I've been thinking about this and I think it works but > I'm still kind of torn about not having devicetree bindings. > It doesn't _preclude_ devicetree bindings but I'd hate to > merge this and then end up with something incompatible. > I do want to support non-Android use cases too. > >>> Sorry, what do you mean by non-Android cases? > >> > >> Any user of Ion that isn't tied to Android. This includes other > >> userspace frameworks as well as non-devicetree targets. > >> > > Sorry, don't follow you ... I tested the patch on Ubuntu machine - so > > the non-Android and non-devicetree case is obviously supported :) > > This patch _doesn't_ provide the required support for devicetree > bindings and Android use case. I'm trying to balance wanting > to support this use case with knowing that the Android use > case is still unsolved. > > Laura Correct, but it does provide the way to instantiate the heaps by the parameters (no matter how we get them). Probably I'm wrong but it's difficult to think about something more generic. Alexey ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 116/120] fs/ceph/super.c:932:7: error: void value not ignored as it ought to be
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: b23ebf4cbbc7a340acc9126d1fff4d39b20ef364
commit: 7c11b3df5cac0ff8a580a81f0b8a92148d66dc81 [116/120] ceph: fix changelog
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 7c11b3df5cac0ff8a580a81f0b8a92148d66dc81
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
fs/ceph/super.c: In function 'ceph_real_mount':
>> fs/ceph/super.c:932:7: error: void value not ignored as it ought to be
err = ceph_fs_debugfs_init(fsc);
^
vim +932 fs/ceph/super.c
16725b9d Sage Weil 2009-10-06 895
3d14c5d2 Yehuda Sadeh 2010-04-06 896
3d14c5d2 Yehuda Sadeh 2010-04-06 897
3d14c5d2 Yehuda Sadeh 2010-04-06 898
16725b9d Sage Weil 2009-10-06 899 /*
16725b9d Sage Weil 2009-10-06 900 * mount: join the ceph cluster,
and open root directory.
16725b9d Sage Weil 2009-10-06 901 */
3f384954 Yan, Zheng 2016-04-21 902 static struct dentry
*ceph_real_mount(struct ceph_fs_client *fsc)
16725b9d Sage Weil 2009-10-06 903 {
16725b9d Sage Weil 2009-10-06 904 int err;
16725b9d Sage Weil 2009-10-06 905 unsigned long started =
jiffies; /* note the start time */
16725b9d Sage Weil 2009-10-06 906 struct dentry *root;
16725b9d Sage Weil 2009-10-06 907
132ca7e1 Yan, Zheng 2016-03-12 908 dout("mount start %p\n", fsc);
3d14c5d2 Yehuda Sadeh 2010-04-06 909
mutex_lock(&fsc->client->mount_mutex);
16725b9d Sage Weil 2009-10-06 910
132ca7e1 Yan, Zheng 2016-03-12 911 if (!fsc->sb->s_root) {
ce2728aa Yan, Zheng 2016-09-14 912 const char *path;
3d14c5d2 Yehuda Sadeh 2010-04-06 913 err =
__ceph_open_session(fsc->client, started);
16725b9d Sage Weil 2009-10-06 914 if (err < 0)
16725b9d Sage Weil 2009-10-06 915 goto out;
16725b9d Sage Weil 2009-10-06 916
1d8f8360 Yan, Zheng 2017-06-27 917 /* setup fscache */
1d8f8360 Yan, Zheng 2017-06-27 918 if
(fsc->mount_options->flags & CEPH_MOUNT_OPT_FSCACHE) {
1d8f8360 Yan, Zheng 2017-06-27 919 err =
ceph_fscache_register_fs(fsc);
1d8f8360 Yan, Zheng 2017-06-27 920 if (err < 0)
1d8f8360 Yan, Zheng 2017-06-27 921 goto
out;
1d8f8360 Yan, Zheng 2017-06-27 922 }
1d8f8360 Yan, Zheng 2017-06-27 923
ce2728aa Yan, Zheng 2016-09-14 924 if
(!fsc->mount_options->server_path) {
ce2728aa Yan, Zheng 2016-09-14 925 path = "";
ce2728aa Yan, Zheng 2016-09-14 926 dout("mount
opening path \\t\n");
ce2728aa Yan, Zheng 2016-09-14 927 } else {
ce2728aa Yan, Zheng 2016-09-14 928 path =
fsc->mount_options->server_path + 1;
ce2728aa Yan, Zheng 2016-09-14 929 dout("mount
opening path %s\n", path);
ce2728aa Yan, Zheng 2016-09-14 930 }
18106734 Chengguang Xu 2018-02-09 931
18106734 Chengguang Xu 2018-02-09 @932 err =
ceph_fs_debugfs_init(fsc);
18106734 Chengguang Xu 2018-02-09 933 if (err < 0)
18106734 Chengguang Xu 2018-02-09 934 goto out;
18106734 Chengguang Xu 2018-02-09 935
ce2728aa Yan, Zheng 2016-09-14 936 root =
open_root_dentry(fsc, path, started);
16725b9d Sage Weil 2009-10-06 937 if (IS_ERR(root)) {
16725b9d Sage Weil 2009-10-06 938 err =
PTR_ERR(root);
16725b9d Sage Weil 2009-10-06 939 goto out;
16725b9d Sage Weil 2009-10-06 940 }
ce2728aa Yan, Zheng 2016-09-14 941 fsc->sb->s_root =
dget(root);
31ca5878 Geert Uytterhoeven 2016-10-13 942 } else {
31ca5878 Geert Uytterhoeven 2016-10-13 943 root =
dget(fsc->sb->s_root);
3d14c5d2 Yehuda Sadeh 2010-04-06 944 }
16725b9d Sage Weil 2009-10-06 945
3d14c5d2 Yehuda Sadeh 2010-04-06 946 fsc->mount_state =
CEPH_MOUNT_MOUNTED;
16725b9d Sage Weil 2009-10-06 947 dout("mount success\n");
a7f9fb20 Al Viro2010-07-26 948
mutex_unlock(&fsc->client->mount_mutex);
a7f9fb20 Al Viro2010-07-26 949 return root;
16725b9d Sage Weil 2009-10-06 950
132ca7e1 Yan, Zheng 2016-03-12 951 out:
132ca7e1 Yan, Zheng 2016-03-12 952
mutex_unlock(&fsc->client->mount_mutex);
132ca7e1 Yan, Zheng 2016-03-12 953 return ERR_PTR(err);
16725b9d Sage Weil 2009-1
RE: [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor
From: Marc Zyngier Sent: Thursday, December 13, 2018
3:23 AM
> >> As Will said, this isn't a viable option. Please follow SMCCC 1.1.
> >
> > I'll have to start a conversation with the Hyper-V team about this.
> > I don't know why they chose to use HVC #1 or this register scheme
> > for output values. It may be tough to change at this point because
> > there are Windows guests on Hyper-V for ARM64 that are already
> > using this approach.
>
> I appreciate you already have stuff in the wild, but there is definitely
> a case to be made for supporting architecturally specified mechanisms in
> a hypervisor, and SMCCC is definitely part of it (I'm certainly curious
> of how you support the Spectre mitigation otherwise).
>
The Hyper-V guys I need to discuss this with are not back from the
holidays until January 7th. I'll follow up on this thread once I've
had that conversation.
> >>> +static int hv_cpu_init(unsigned int cpu)
> >>> +{
> >>> + u64 msr_vp_index;
> >>> +
> >>> + hv_get_vp_index(msr_vp_index);
> >>> +
> >>> + hv_vp_index[smp_processor_id()] = msr_vp_index;
> >>> +
> >>> + if (msr_vp_index > hv_max_vp_index)
> >>> + hv_max_vp_index = msr_vp_index;
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> Is that some new way to describe a CPU topology? If so, why isn't that
> >> exposed via the ACPI tables that the kernel already parses?
> >
> > Hyper-V's hypercall interface uses vCPU identifiers that are not
> > guaranteed to be consecutive integers or to match what ACPI shows.
> > No topology information is implied -- it's just unique identifiers. The
> > hv_vp_index array provides easy mapping from Linux's consecutive
> > integer IDs for CPUs when needed to construct hypercall arguments.
>
> That's extremely odd. The hypervisor obviously knows which vCPU is doing
> a hypercall, and if referencing another vCPU, the virtualized MPIDR_EL1
> value should be used. I don't think deviating from the architecture is a
> good idea (but I appreciate this is none of your doing). Following the
> architecture would allow this code to directly use the cpu_logical_map
> infrastructure we already have.
I see what you are getting at. However, some Hyper-V hypercalls allow
specifying arbitrary sets of vCPUs. These hypercalls are used to define
target processors in the virtual PCI code (which I have not yet brought over
to ARM64) and in enlightenments for IPIs and TLB flushes (used by
Windows guests and Linux guests on x86, but not yet brought over to Linux
ARM64, if they ever will be). These hypercalls take bitmaps as arguments,
similar to a Linux cpumask, as defined in Sections 7.8.7.3 thru 7.8.7.5 in the
Hyper-V TLFS. So Hyper-V defines its own VP index that is akin to the index
into the cpu_logical_map, though it may not be the same mapping. My earlier
comments may have been misleading -- the Hyper-V VP index is an integer
ranging from 0 thru (# vCPUs - 1).
With these requirements, Hyper-V defining its own VP index seems like
a reasonable thing to do. And since Hyper-V provides the same hypercall
interfaces for both x86 and ARM64 implementations, and for Windows
guests, there's not much choice but to use the Hyper-V VP index as specified.
Michael
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: android: ion: Add implementation of dma_buf_vmap and dma_buf_vunmap
On Tue, 18 Dec 2018, Alexey Skidanov wrote: > >>> I was wondering if we could re-open the discussion on adding support to > >>> ION for dma_buf_vmap. > >>> It seems like the patch was not taken as the reviewers wanted more > >>> evidence of an upstream use case. > >>> > >>> Here would be my upstream usage argument for including dma_buf_vmap > >>> support in ION. > >>> > >>> Currently all calls to ion_dma_buf_begin_cpu_access result in the > >>> creation > >>> of a kernel mapping for the buffer, unfortunately the resulting call to > >>> alloc_vmap_area can be quite expensive and this has caused a performance > >>> regression for certain clients when they have moved to the new version of > >>> ION. > >>> > >>> The kernel mapping is not actually needed in > >>> ion_dma_buf_begin_cpu_access, > >>> and generally isn't needed by clients. So if we remove the creation of > >>> the > >>> kernel mapping in ion_dma_buf_begin_cpu_access and only create it when > >>> needed we can speed up the calls to ion_dma_buf_begin_cpu_access. > >>> > >>> An additional benefit of removing the creation of kernel mappings from > >>> ion_dma_buf_begin_cpu_access is that it makes the ION code more secure. > >>> Currently a malicious client could call the DMA_BUF_IOCTL_SYNC IOCTL with > >>> flags DMA_BUF_SYNC_END multiple times to cause the ION buffer kmap_cnt to > >>> go negative which could lead to undesired behavior. > >>> > >>> One disadvantage of the above change is that a kernel mapping is not > >>> already created when a client calls dma_buf_kmap. So the following > >>> dma_buf_kmap contract can't be satisfied. > >>> > >>> /** > >>> * dma_buf_kmap - Map a page of the buffer object into kernel address > >>> space. The > >>> * same restrictions as for kmap and friends apply. > >>> * @dmabuf:[in]buffer to map page from. > >>> * @page_num: [in]page in PAGE_SIZE units to map. > >>> * > >>> * This call must always succeed, any necessary preparations that might > >>> fail > >>> * need to be done in begin_cpu_access. > >>> */ > >>> > >>> But hopefully we can work around this by moving clients to dma_buf_vmap. > >> I think the problem is with the contract. We can't ensure that the call > >> is always succeeds regardless the implementation - any mapping might > >> fail. Probably this is why *all* clients of dma_buf_kmap() check the > >> return value (so it's safe to return NULL in case of failure). > >> > > > > I think currently the call to dma_buf_kmap will always succeed since the > > DMA-Buf contract requires that the client first successfully call > > dma_buf_begin_cpu_access(), and if dma_buf_begin_cpu_access() succeeds > > then dma_buf_kmap will succeed. > > > >> I would suggest to fix the contract and to keep the dma_buf_kmap() > >> support in ION. > > > > I will leave it to the DMA-Buf maintainers as to whether they want to > > change their contract. > > > > Liam > > > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > a Linux Foundation Collaborative Project > > > > Ok. We need the list of the clients using the ION in the mainline tree. > Looks to me like the only functions which might be calling dma_buf_kmap/dma_buf_kunmap on ION buffers are tegra_bo_kmap/tegra_bo_kunmap, I assume Tegra is used in some Android automotive products. Looks like these functions could be moved over to using dma_buf_vmap/dma_buf_vunmap but it wouldn't be very clean and would add a performance hit. Liam Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 104/109] net//ceph/debugfs.c:392:13: error: conflicting types for 'ceph_debugfs_init'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: ead253d78760f569593267b87592175cc66b0f99
commit: 361252cd04527c4f4f5ea7d96f5571cbeb670b8a [104/109] ceph: fix changelog
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 361252cd04527c4f4f5ea7d96f5571cbeb670b8a
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=m68k
All errors (new ones prefixed by >>):
>> net//ceph/debugfs.c:392:13: error: conflicting types for 'ceph_debugfs_init'
void __init ceph_debugfs_init(void)
^
In file included from net//ceph/debugfs.c:14:0:
include/linux/ceph/debugfs.h:22:12: note: previous declaration of
'ceph_debugfs_init' was here
extern int ceph_debugfs_init(void);
^
>> net//ceph/debugfs.c:402:6: error: conflicting types for
>> 'ceph_debugfs_client_init'
void ceph_debugfs_client_init(struct ceph_client *client)
^~~~
In file included from net//ceph/debugfs.c:14:0:
include/linux/ceph/debugfs.h:24:12: note: previous declaration of
'ceph_debugfs_client_init' was here
extern int ceph_debugfs_client_init(struct ceph_client *client);
^~~~
vim +/ceph_debugfs_init +392 net//ceph/debugfs.c
391
> 392 void __init ceph_debugfs_init(void)
393 {
394 ceph_debugfs_dir = debugfs_create_dir("ceph", NULL);
395 }
396
397 void ceph_debugfs_cleanup(void)
398 {
399 debugfs_remove(ceph_debugfs_dir);
400 }
401
> 402 void ceph_debugfs_client_init(struct ceph_client *client)
403 {
404 char name[80];
405
406 snprintf(name, sizeof(name), "%pU.client%lld", &client->fsid,
407 client->monc.auth->global_id);
408
409 dout("ceph_debugfs_client_init %p %s\n", client, name);
410
411 client->debugfs_dir = debugfs_create_dir(name,
ceph_debugfs_dir);
412
413 client->monc.debugfs_file = debugfs_create_file("monc",
4140400,
415
client->debugfs_dir,
416client,
417&monc_show_fops);
418
419 client->osdc.debugfs_file = debugfs_create_file("osdc",
4200400,
421
client->debugfs_dir,
422client,
423&osdc_show_fops);
424
425 client->debugfs_monmap = debugfs_create_file("monmap",
426 0400,
427 client->debugfs_dir,
428 client,
429 &monmap_show_fops);
430
431 client->debugfs_osdmap = debugfs_create_file("osdmap",
432 0400,
433 client->debugfs_dir,
434 client,
435 &osdmap_show_fops);
436
437 client->debugfs_options = debugfs_create_file("client_options",
438 0400,
439 client->debugfs_dir,
440 client,
441 &client_options_show_fops);
442 }
443
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 102/109] net//6lowpan/core.c:51:6: error: void value not ignored as it ought to be
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: ead253d78760f569593267b87592175cc66b0f99
commit: a1e3d1d072efed7a835376d1b17c21ae9021b9a7 [102/109] 6lowpan: fix
changelog
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a1e3d1d072efed7a835376d1b17c21ae9021b9a7
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=m68k
All errors (new ones prefixed by >>):
net//6lowpan/core.c: In function 'lowpan_register_netdevice':
>> net//6lowpan/core.c:51:6: error: void value not ignored as it ought to be
ret = lowpan_dev_debugfs_init(dev);
^
vim +51 net//6lowpan/core.c
b1815fd9 Alexander Aring 2015-12-09 20
00f59314 Alexander Aring 2015-12-09 21 int lowpan_register_netdevice(struct
net_device *dev,
00f59314 Alexander Aring 2015-12-09 22 enum
lowpan_lltypes lltype)
b72f6f51 Alexander Aring 2015-08-11 23 {
5609c185 Alexander Aring 2016-02-22 24 int i, ret;
b1815fd9 Alexander Aring 2015-12-09 25
be054fc8 Patrik Flykt2017-03-12 26 switch (lltype) {
be054fc8 Patrik Flykt2017-03-12 27 case LOWPAN_LLTYPE_IEEE802154:
4d6a6aed Alexander Aring 2015-10-02 28 dev->addr_len =
EUI64_ADDR_LEN;
be054fc8 Patrik Flykt2017-03-12 29 break;
be054fc8 Patrik Flykt2017-03-12 30
be054fc8 Patrik Flykt2017-03-12 31 case LOWPAN_LLTYPE_BTLE:
be054fc8 Patrik Flykt2017-03-12 32 dev->addr_len =
ETH_ALEN;
be054fc8 Patrik Flykt2017-03-12 33 break;
be054fc8 Patrik Flykt2017-03-12 34 }
be054fc8 Patrik Flykt2017-03-12 35
4d6a6aed Alexander Aring 2015-10-02 36 dev->type = ARPHRD_6LOWPAN;
4d6a6aed Alexander Aring 2015-10-02 37 dev->mtu = IPV6_MIN_MTU;
4d6a6aed Alexander Aring 2015-10-02 38
2e4d60cb Alexander Aring 2016-04-11 39 lowpan_dev(dev)->lltype =
lltype;
00f59314 Alexander Aring 2015-12-09 40
2e4d60cb Alexander Aring 2016-04-11 41
spin_lock_init(&lowpan_dev(dev)->ctx.lock);
5609c185 Alexander Aring 2016-02-22 42 for (i = 0; i <
LOWPAN_IPHC_CTX_TABLE_SIZE; i++)
2e4d60cb Alexander Aring 2016-04-11 43
lowpan_dev(dev)->ctx.table[i].id = i;
5609c185 Alexander Aring 2016-02-22 44
bbe5f5ce Alexander Aring 2016-06-15 45 dev->ndisc_ops =
&lowpan_ndisc_ops;
bbe5f5ce Alexander Aring 2016-06-15 46
92e17ee7 Alexander Aring 2015-12-15 47 ret = register_netdevice(dev);
b1815fd9 Alexander Aring 2015-12-09 48 if (ret < 0)
b1815fd9 Alexander Aring 2015-12-09 49 return ret;
b1815fd9 Alexander Aring 2015-12-09 50
92e17ee7 Alexander Aring 2015-12-15 @51 ret =
lowpan_dev_debugfs_init(dev);
b1815fd9 Alexander Aring 2015-12-09 52 if (ret < 0)
92e17ee7 Alexander Aring 2015-12-15 53
unregister_netdevice(dev);
b1815fd9 Alexander Aring 2015-12-09 54
b1815fd9 Alexander Aring 2015-12-09 55 return ret;
00f59314 Alexander Aring 2015-12-09 56 }
00f59314 Alexander Aring 2015-12-09 57
EXPORT_SYMBOL(lowpan_register_netdevice);
00f59314 Alexander Aring 2015-12-09 58
:: The code at line 51 was first introduced by commit
:: 92e17ee72a60b126263cbcd749e5da688e0198a3 6lowpan: fix debugfs interface
entry name
:: TO: Alexander Aring
:: CC: Marcel Holtmann
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 102/109] net/6lowpan/debugfs.c:182:2: error: 'root' undeclared; did you mean 'ror8'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: ead253d78760f569593267b87592175cc66b0f99
commit: a1e3d1d072efed7a835376d1b17c21ae9021b9a7 [102/109] 6lowpan: fix
changelog
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a1e3d1d072efed7a835376d1b17c21ae9021b9a7
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=m68k
All error/warnings (new ones prefixed by >>):
net/6lowpan/debugfs.c: In function 'lowpan_dev_debugfs_ctx_init':
>> net/6lowpan/debugfs.c:182:2: error: 'root' undeclared (first use in this
>> function); did you mean 'ror8'?
root = debugfs_create_dir(buf, ctx);
^~~~
ror8
net/6lowpan/debugfs.c:182:2: note: each undeclared identifier is reported
only once for each function it appears in
>> net/6lowpan/debugfs.c:195:1: warning: no return statement in function
>> returning non-void [-Wreturn-type]
}
^
net/6lowpan/debugfs.c: In function 'lowpan_dev_debugfs_802154_init':
>> net/6lowpan/debugfs.c:240:10: warning: 'return' with a value, in function
>> returning void
return 0;
^
net/6lowpan/debugfs.c:234:13: note: declared here
static void lowpan_dev_debugfs_802154_init(const struct net_device *dev,
^~
net/6lowpan/debugfs.c: At top level:
>> net/6lowpan/debugfs.c:249:5: error: conflicting types for
>> 'lowpan_dev_debugfs_init'
int lowpan_dev_debugfs_init(struct net_device *dev)
^~~
In file included from net/6lowpan/debugfs.c:17:0:
net/6lowpan/6lowpan_i.h:21:6: note: previous declaration of
'lowpan_dev_debugfs_init' was here
void lowpan_dev_debugfs_init(struct net_device *dev);
^~~
net/6lowpan/debugfs.c: In function 'lowpan_dev_debugfs_init':
>> net/6lowpan/debugfs.c:267:1: warning: control reaches end of non-void
>> function [-Wreturn-type]
}
^
vim +182 net/6lowpan/debugfs.c
5609c185 Alexander Aring2016-02-22 171
5609c185 Alexander Aring2016-02-22 172 static int
lowpan_dev_debugfs_ctx_init(struct net_device *dev,
5609c185 Alexander Aring2016-02-22 173
struct dentry *ctx, u8 id)
5609c185 Alexander Aring2016-02-22 174 {
2e4d60cb Alexander Aring2016-04-11 175 struct lowpan_dev *ldev =
lowpan_dev(dev);
5609c185 Alexander Aring2016-02-22 176 char buf[32];
5609c185 Alexander Aring2016-02-22 177
5609c185 Alexander Aring2016-02-22 178 WARN_ON_ONCE(id >
LOWPAN_IPHC_CTX_TABLE_SIZE);
5609c185 Alexander Aring2016-02-22 179
5609c185 Alexander Aring2016-02-22 180 sprintf(buf, "%d", id);
5609c185 Alexander Aring2016-02-22 181
5609c185 Alexander Aring2016-02-22 @182 root = debugfs_create_dir(buf,
ctx);
5609c185 Alexander Aring2016-02-22 183
a1e3d1d0 Greg Kroah-Hartman 2019-01-04 184 debugfs_create_file("active",
0644, root, &ldev->ctx.table[id],
5609c185 Alexander Aring2016-02-22 185
&lowpan_ctx_flag_active_fops);
5609c185 Alexander Aring2016-02-22 186
a1e3d1d0 Greg Kroah-Hartman 2019-01-04 187
debugfs_create_file("compression", 0644, root, &ldev->ctx.table[id],
5609c185 Alexander Aring2016-02-22 188
&lowpan_ctx_flag_c_fops);
5609c185 Alexander Aring2016-02-22 189
a1e3d1d0 Greg Kroah-Hartman 2019-01-04 190 debugfs_create_file("prefix",
0644, root, &ldev->ctx.table[id],
5609c185 Alexander Aring2016-02-22 191
&lowpan_ctx_pfx_fops);
5609c185 Alexander Aring2016-02-22 192
a1e3d1d0 Greg Kroah-Hartman 2019-01-04 193
debugfs_create_file("prefix_len", 0644, root, &ldev->ctx.table[id],
5609c185 Alexander Aring2016-02-22 194
&lowpan_ctx_plen_fops);
5609c185 Alexander Aring2016-02-22 @195 }
5609c185 Alexander Aring2016-02-22 196
5609c185 Alexander Aring2016-02-22 197 static int
lowpan_context_show(struct seq_file *file, void *offset)
5609c185 Alexander Aring2016-02-22 198 {
5609c185 Alexander Aring2016-02-22 199 struct lowpan_iphc_ctx_table *t
= file->private;
5609c185 Alexander Aring2016-02-22 200 int i;
5609c185 Alexander Aring2016-02-22 201
5609c185 Alexander Aring2016-02-22 202 seq_printf(file,
"%3s|%-43s|%c\n", "cid", "prefix", 'C');
5609c185 Alexander Aring2016-02-22 203 seq_puts(file,
"-\n");
5609c185 Alexander Aring2016-02-22 204
5609c185 Alexander Aring2016-02-22 205 spin_lock_bh(&t->lock);
5609c185 Alexander Aring2016-02-22 206 for (i = 0; i <
LOWPAN_IPHC_CTX_TABLE_S
[driver-core:debugfs_cleanup 106/109] net/sunrpc/debugfs.c:321:2: error: 'rpc_faultdir' undeclared; did you mean 'rpc_fault_dir'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: ead253d78760f569593267b87592175cc66b0f99
commit: 4e0d6f855ab212b7a13c28925da7c8ec497f7807 [106/109] sunrpc: fix changelog
config: nios2-10m50_defconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4e0d6f855ab212b7a13c28925da7c8ec497f7807
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=nios2
All errors (new ones prefixed by >>):
net/sunrpc/debugfs.c: In function 'sunrpc_debugfs_init':
>> net/sunrpc/debugfs.c:321:2: error: 'rpc_faultdir' undeclared (first use in
>> this function); did you mean 'rpc_fault_dir'?
rpc_faultdir = debugfs_create_dir("inject_fault", topdir);
^~~~
rpc_fault_dir
net/sunrpc/debugfs.c:321:2: note: each undeclared identifier is reported
only once for each function it appears in
vim +321 net/sunrpc/debugfs.c
311
312 void __init
313 sunrpc_debugfs_init(void)
314 {
315 topdir = debugfs_create_dir("sunrpc", NULL);
316
317 rpc_clnt_dir = debugfs_create_dir("rpc_clnt", topdir);
318
319 rpc_xprt_dir = debugfs_create_dir("rpc_xprt", topdir);
320
> 321 rpc_faultdir = debugfs_create_dir("inject_fault", topdir);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] hv_balloon: avoid touching uninitialized struct page during tail onlining
Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use 128M. To deal with it we implement partial section onlining by registering custom page onlining callback (hv_online_page()). Later, when more memory arrives we try to online the 'tail' (see hv_bring_pgs_online()). It was found that in some cases this 'tail' onlining causes issues: BUG: Bad page state in process kworker/0:2 pfn:109e3a page:e08344278e80 count:0 mapcount:1 mapping: index:0x0 flags: 0xf8000() raw: 000f8000 dead0100 dead0200 raw: page dumped because: nonzero mapcount ... Workqueue: events hot_add_req [hv_balloon] Call Trace: dump_stack+0x5c/0x80 bad_page.cold.112+0x7f/0xb2 free_pcppages_bulk+0x4b8/0x690 free_unref_page+0x54/0x70 hv_page_online_one+0x5c/0x80 [hv_balloon] hot_add_req.cold.24+0x182/0x835 [hv_balloon] ... Turns out that we now have deferred struct page initialization for memory hotplug so e.g. memory_block_action() in drivers/base/memory.c does pages_correctly_probed() check and in that check it avoids inspecting struct pages and checks sections instead. But in Hyper-V balloon driver we do PageReserved(pfn_to_page()) check and this is now wrong. Switch to checking online_section_nr() instead. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_balloon.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 5301fef16c31..7c6349a50ef1 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -888,12 +888,14 @@ static unsigned long handle_pg_range(unsigned long pg_start, pfn_cnt -= pgs_ol; /* * Check if the corresponding memory block is already -* online by checking its last previously backed page. -* In case it is we need to bring rest (which was not -* backed previously) online too. +* online. It is possible to observe struct pages still +* being uninitialized here so check section instead. +* In case the section is online we need to bring the +* rest of pfns (which were not backed previously) +* online too. */ if (start_pfn > has->start_pfn && - !PageReserved(pfn_to_page(start_pfn - 1))) + online_section_nr(pfn_to_section_nr(start_pfn))) hv_bring_pgs_online(has, start_pfn, pgs_ol); } -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops
dt_node_to_map and dt_free_map operations can use pinconf-generic API's instead of redefine operations in the driver. Make use of them cleaning a bit driver's code and fixing a runtime warning. Update DT accordly to make sure used bindings property in code match with the board's DT bindings. Both patches must be applied to properly fix the problem. Changes in v2: - Rebase properly onto staging-next - Add tags 'Tested-by', 'Fixes' and 'Reported-by' - Re-do commit message describing the fixed problem. Sergio Paracuellos (2): staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and 'dt_free_map' staging: mt7621-dts: use standard 'groups' instead of 'group' for pinctrl bindings drivers/staging/mt7621-dts/gbpc1.dts | 4 +- drivers/staging/mt7621-dts/mt7621.dtsi| 24 +-- drivers/staging/mt7621-pinctrl/Kconfig| 1 + .../staging/mt7621-pinctrl/pinctrl-rt2880.c | 41 ++- 4 files changed, 18 insertions(+), 52 deletions(-) -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and 'dt_free_map'
Instead of reimplement afunction to do 'dt_node_to_map' task like
'rt2880_pinctrl_dt_node_to_map' make use of 'pinconf_generic_dt_node_to_map_all'
generic function for this task. Also use its equivalent function for free which
is 'pinconf_generic_dt_free_map'. Remove 'rt2880_pinctrl_dt_node_to_map'
function
which is not needed anymore. This decrease a bit driver LOC and make it more
generic. To properly compile this changes 'GENERIC_PINCONF' option is selected
with the driver in its Kconfig file.
This also fix a problem with function 'rt2880_pinctrl_dt_node_to_map' which was
calling internally 'pinctrl_utils_reserve_map' which expects 'num_maps' to be
initialized.
It does a memory allocation based on the value, and triggers the following
warning if is not properly set:
if (unlikely(order >= MAX_ORDER)) {
WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
return NULL;
}
Generic function 'pinconf_generic_dt_node_to_map_all' initializes properly
'num_maps' to zero fixing the problem.
Fixes: e12a1a6e087b ("staging: mt7621-pinctrl: refactor
rt2880_pinctrl_dt_node_to_map function")
Reported-by: NeilBrown
Tested-by: NeilBrown
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pinctrl/Kconfig| 1 +
.../staging/mt7621-pinctrl/pinctrl-rt2880.c | 41 ++-
2 files changed, 4 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/mt7621-pinctrl/Kconfig
b/drivers/staging/mt7621-pinctrl/Kconfig
index 37cf9c3273be..fc3612711307 100644
--- a/drivers/staging/mt7621-pinctrl/Kconfig
+++ b/drivers/staging/mt7621-pinctrl/Kconfig
@@ -2,3 +2,4 @@ config PINCTRL_RT2880
bool "RT2800 pinctrl driver for RALINK/Mediatek SOCs"
depends on RALINK
select PINMUX
+ select GENERIC_PINCONF
diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
index aa98fbb17013..80e7067cfb79 100644
--- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -73,48 +74,12 @@ static int rt2880_get_group_pins(struct pinctrl_dev
*pctrldev,
return 0;
}
-static int rt2880_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrldev,
-struct device_node *np_config,
-struct pinctrl_map **map,
-unsigned int *num_maps)
-{
- struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
- struct property *prop;
- const char *function_name, *group_name;
- int ret;
- int ngroups = 0;
- unsigned int reserved_maps = 0;
-
- for_each_node_with_property(np_config, "group")
- ngroups++;
-
- *map = NULL;
- ret = pinctrl_utils_reserve_map(pctrldev, map, &reserved_maps,
- num_maps, ngroups);
- if (ret) {
- dev_err(p->dev, "can't reserve map: %d\n", ret);
- return ret;
- }
-
- of_property_for_each_string(np_config, "group", prop, group_name) {
- ret = pinctrl_utils_add_map_mux(pctrldev, map, &reserved_maps,
- num_maps, group_name,
- function_name);
- if (ret) {
- dev_err(p->dev, "can't add map: %d\n", ret);
- return ret;
- }
- }
-
- return 0;
-}
-
static const struct pinctrl_ops rt2880_pctrl_ops = {
.get_groups_count = rt2880_get_group_count,
.get_group_name = rt2880_get_group_name,
.get_group_pins = rt2880_get_group_pins,
- .dt_node_to_map = rt2880_pinctrl_dt_node_to_map,
- .dt_free_map= pinctrl_utils_free_map,
+ .dt_node_to_map = pinconf_generic_dt_node_to_map_all,
+ .dt_free_map= pinconf_generic_dt_free_map,
};
static int rt2880_pmx_func_count(struct pinctrl_dev *pctrldev)
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: mt7621-dts: use standard 'groups' instead of 'group' for pinctrl bindings
Pinctrl generic functions looks for standard property 'groups' in DT to get
data and use in the driver. Change all of them.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/gbpc1.dts | 4 ++--
drivers/staging/mt7621-dts/mt7621.dtsi | 24
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
b/drivers/staging/mt7621-dts/gbpc1.dts
index 6a1699ce9455..b73385540216 100644
--- a/drivers/staging/mt7621-dts/gbpc1.dts
+++ b/drivers/staging/mt7621-dts/gbpc1.dts
@@ -136,8 +136,8 @@
&pinctrl {
state_default: pinctrl0 {
gpio {
- ralink,group = "wdt", "rgmii2", "uart3";
- ralink,function = "gpio";
+ groups = "wdt", "rgmii2", "uart3";
+ function = "gpio";
};
};
};
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 0cbc298ed457..f0c51622eca1 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -204,82 +204,82 @@
i2c_pins: i2c0 {
i2c0 {
- group = "i2c";
+ groups = "i2c";
function = "i2c";
};
};
spi_pins: spi0 {
spi0 {
- group = "spi";
+ groups = "spi";
function = "spi";
};
};
uart1_pins: uart1 {
uart1 {
- group = "uart1";
+ groups = "uart1";
function = "uart1";
};
};
uart2_pins: uart2 {
uart2 {
- group = "uart2";
+ groups = "uart2";
function = "uart2";
};
};
uart3_pins: uart3 {
uart3 {
- group = "uart3";
+ groups = "uart3";
function = "uart3";
};
};
rgmii1_pins: rgmii1 {
rgmii1 {
- group = "rgmii1";
+ groups = "rgmii1";
function = "rgmii1";
};
};
rgmii2_pins: rgmii2 {
rgmii2 {
- group = "rgmii2";
+ groups = "rgmii2";
function = "rgmii2";
};
};
mdio_pins: mdio0 {
mdio0 {
- group = "mdio";
+ groups = "mdio";
function = "mdio";
};
};
pcie_pins: pcie0 {
pcie0 {
- group = "pcie";
+ groups = "pcie";
function = "pcie rst";
};
};
nand_pins: nand0 {
spi-nand {
- group = "spi";
+ groups = "spi";
function = "nand1";
};
sdhci-nand {
- group = "sdhci";
+ groups = "sdhci";
function = "nand2";
};
};
sdhci_pins: sdhci0 {
sdhci0 {
- group = "sdhci";
+ groups = "sdhci";
function = "sdhci";
};
};
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops
On Fri, Jan 4, 2019 at 10:05 AM Greg KH wrote: > > On Fri, Jan 04, 2019 at 09:55:02AM +0100, Sergio Paracuellos wrote: > > Hi Greg, > > > > On Fri, Jan 4, 2019 at 9:32 AM Greg KH wrote: > > > > > > On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote: > > > > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown wrote: > > > > > > > > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote: > > > > > > > > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic > > > > > > API's > > > > > > instead of redefine operations in the driver. Make use of them > > > > > > cleaning > > > > > > a bit driver's code. > > > > > > > > > > > > Update DT accordly to make sure used bindings property in code match > > > > > > with the board's DT bindings. > > > > > > > > > > > > Changes are only compile-tested. > > > > > > > > > > Thanks. This appears to work for me. > > > > > It is awkward to test pinctrl changes because the firmware > > > > > preconfigures > > > > > all the pins, so the hardware will work correctly if pinctrl does > > > > > nothing. > > > > > So I change the dts file to mis-configure some pins for driving LEDs, > > > > > and checked that the LEDs broken. The fixed the dts, and the LEDs > > > > > started working again. > > > > > I think that will have to do. > > > > > > > > > > Tested-by: NeilBrown > > > > > > > > > > Thanks, > > > > > NeilBrown > > > > > > > > Cool! Thanks for testing and let me know. > > > > > > > > So, I sent this patch which solves a problem: > > > > > > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html > > > > > > > > And this new patch is generated with that applied. Also this patch > > > > solves the original problem > > > > also and seems the way to go... Should be better to re-do this one > > > > with all the fixed and reported by > > > > tags added as a solution? > > > > > > > > What do you prefer, Greg? > > > > > > I'm sorry, but I do not understand. Is this 2 patch series not > > > acceptable to merge? Should I drop it and use some other patch series? > > > Should I ignore some other patch series? > > > > Sorry, let me try to explain it better. > > Both this series and the patch in [1] can solve the same problem. Both > > of them also work. This series can be applied after the patch in [1]. > > as a clean up because this series are rebased onto it. So the question > > here is you don't have problems to take both of them or if I should > > re-do this one with two patches as a solution of the problem and > > forget about the one in [1]. > > > > [1]: > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html > > How about I drop all of the pending patches from you, and you resend a > new series with whatever you think needs to be applied. That makes it > very obvious as to what I need to ignore and what I need to > review/apply. Ok. I'll send the last series as a fix. Sorry for the noise. > > thanks, > > greg k-h Best regards, Sergio Paracuellos ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops
On Fri, Jan 04, 2019 at 09:55:02AM +0100, Sergio Paracuellos wrote: > Hi Greg, > > On Fri, Jan 4, 2019 at 9:32 AM Greg KH wrote: > > > > On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote: > > > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown wrote: > > > > > > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote: > > > > > > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic > > > > > API's > > > > > instead of redefine operations in the driver. Make use of them > > > > > cleaning > > > > > a bit driver's code. > > > > > > > > > > Update DT accordly to make sure used bindings property in code match > > > > > with the board's DT bindings. > > > > > > > > > > Changes are only compile-tested. > > > > > > > > Thanks. This appears to work for me. > > > > It is awkward to test pinctrl changes because the firmware preconfigures > > > > all the pins, so the hardware will work correctly if pinctrl does > > > > nothing. > > > > So I change the dts file to mis-configure some pins for driving LEDs, > > > > and checked that the LEDs broken. The fixed the dts, and the LEDs > > > > started working again. > > > > I think that will have to do. > > > > > > > > Tested-by: NeilBrown > > > > > > > > Thanks, > > > > NeilBrown > > > > > > Cool! Thanks for testing and let me know. > > > > > > So, I sent this patch which solves a problem: > > > > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html > > > > > > And this new patch is generated with that applied. Also this patch > > > solves the original problem > > > also and seems the way to go... Should be better to re-do this one > > > with all the fixed and reported by > > > tags added as a solution? > > > > > > What do you prefer, Greg? > > > > I'm sorry, but I do not understand. Is this 2 patch series not > > acceptable to merge? Should I drop it and use some other patch series? > > Should I ignore some other patch series? > > Sorry, let me try to explain it better. > Both this series and the patch in [1] can solve the same problem. Both > of them also work. This series can be applied after the patch in [1]. > as a clean up because this series are rebased onto it. So the question > here is you don't have problems to take both of them or if I should > re-do this one with two patches as a solution of the problem and > forget about the one in [1]. > > [1]: > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html How about I drop all of the pending patches from you, and you resend a new series with whatever you think needs to be applied. That makes it very obvious as to what I need to ignore and what I need to review/apply. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops
Hi Greg, On Fri, Jan 4, 2019 at 9:32 AM Greg KH wrote: > > On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote: > > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown wrote: > > > > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote: > > > > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's > > > > instead of redefine operations in the driver. Make use of them cleaning > > > > a bit driver's code. > > > > > > > > Update DT accordly to make sure used bindings property in code match > > > > with the board's DT bindings. > > > > > > > > Changes are only compile-tested. > > > > > > Thanks. This appears to work for me. > > > It is awkward to test pinctrl changes because the firmware preconfigures > > > all the pins, so the hardware will work correctly if pinctrl does > > > nothing. > > > So I change the dts file to mis-configure some pins for driving LEDs, > > > and checked that the LEDs broken. The fixed the dts, and the LEDs > > > started working again. > > > I think that will have to do. > > > > > > Tested-by: NeilBrown > > > > > > Thanks, > > > NeilBrown > > > > Cool! Thanks for testing and let me know. > > > > So, I sent this patch which solves a problem: > > > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html > > > > And this new patch is generated with that applied. Also this patch > > solves the original problem > > also and seems the way to go... Should be better to re-do this one > > with all the fixed and reported by > > tags added as a solution? > > > > What do you prefer, Greg? > > I'm sorry, but I do not understand. Is this 2 patch series not > acceptable to merge? Should I drop it and use some other patch series? > Should I ignore some other patch series? Sorry, let me try to explain it better. Both this series and the patch in [1] can solve the same problem. Both of them also work. This series can be applied after the patch in [1]. as a clean up because this series are rebased onto it. So the question here is you don't have problems to take both of them or if I should re-do this one with two patches as a solution of the problem and forget about the one in [1]. [1]: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html > > totally confused, Hope this clarified things a bit? > > greg k-h Best regards, Sergio Paracuellos ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/11] X86/Hyper-V: Add parameter offset for hyperv_fill_flush_guest_mapping_list()
From: Lan Tianyu
Add parameter offset to specify start position to add flush ranges in
guest address list of struct hv_guest_mapping_flush_list.
Signed-off-by: Lan Tianyu
---
arch/x86/hyperv/nested.c| 4 ++--
arch/x86/include/asm/mshyperv.h | 2 +-
arch/x86/kvm/vmx/vmx.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/hyperv/nested.c b/arch/x86/hyperv/nested.c
index dd0a843f766d..96f8bac7476d 100644
--- a/arch/x86/hyperv/nested.c
+++ b/arch/x86/hyperv/nested.c
@@ -58,11 +58,11 @@ EXPORT_SYMBOL_GPL(hyperv_flush_guest_mapping);
int hyperv_fill_flush_guest_mapping_list(
struct hv_guest_mapping_flush_list *flush,
- u64 start_gfn, u64 pages)
+ int offset, u64 start_gfn, u64 pages)
{
u64 cur = start_gfn;
u64 additional_pages;
- int gpa_n = 0;
+ int gpa_n = offset;
do {
/*
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index cc60e617931c..d6be685ab6b0 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -357,7 +357,7 @@ int hyperv_flush_guest_mapping_range(u64 as,
hyperv_fill_flush_list_func fill_func, void *data);
int hyperv_fill_flush_guest_mapping_list(
struct hv_guest_mapping_flush_list *flush,
- u64 start_gfn, u64 end_gfn);
+ int offset, u64 start_gfn, u64 end_gfn);
#ifdef CONFIG_X86_64
void hv_apic_init(void);
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 87224e4c2fd9..2c159efedc40 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -428,7 +428,7 @@ int kvm_fill_hv_flush_list_func(struct
hv_guest_mapping_flush_list *flush,
{
struct kvm_tlb_range *range = data;
- return hyperv_fill_flush_guest_mapping_list(flush, range->start_gfn,
+ return hyperv_fill_flush_guest_mapping_list(flush, 0, range->start_gfn,
range->pages);
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/11] X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM
From: Lan Tianyu This patchset is to introduce hv ept tlb range list flush function support in the KVM MMU component. Flushing ept tlbs of several address range can be done via single hypercall and new list flush function is used in the kvm_mmu_commit_zap_page() and FNAME(sync_page). This patchset also adds more hv ept tlb range flush support in more KVM MMU function. Lan Tianyu (11): X86/Hyper-V: Add parameter offset for hyperv_fill_flush_guest_mapping_list() KVM/VMX: Fill range list in kvm_fill_hv_flush_list_func() KVM: Add spte's point in the struct kvm_mmu_page KVM/MMU: Introduce tlb flush with range list KVM/MMU: Flush tlb directly in the kvm_mmu_slot_gfn_write_protect() KVM/MMU: Flush tlb with range list in sync_page() KVM: Remove redundant check in the kvm_get_dirty_log_protect() KVM: Make kvm_arch_mmu_enable_log_dirty_pt_masked() return value KVM/MMU: Flush tlb in the kvm_mmu_write_protect_pt_masked() KVM: Add flush parameter for kvm_age_hva() KVM/MMU: Flush tlb in the kvm_age_rmapp() arch/arm/include/asm/kvm_host.h | 3 +- arch/arm64/include/asm/kvm_host.h | 3 +- arch/mips/include/asm/kvm_host.h| 3 +- arch/mips/kvm/mmu.c | 8 +++- arch/powerpc/include/asm/kvm_host.h | 3 +- arch/powerpc/kvm/book3s.c | 3 +- arch/powerpc/kvm/e500_mmu_host.c| 3 +- arch/x86/hyperv/nested.c| 4 +- arch/x86/include/asm/kvm_host.h | 11 +- arch/x86/include/asm/mshyperv.h | 2 +- arch/x86/kvm/mmu.c | 73 - arch/x86/kvm/paging_tmpl.h | 18 - arch/x86/kvm/vmx/vmx.c | 18 - include/linux/kvm_host.h| 2 +- virt/kvm/arm/mmu.c | 8 +++- virt/kvm/kvm_main.c | 18 - 16 files changed, 141 insertions(+), 39 deletions(-) -- 2.14.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt29f_spinand: add SPDX identifiers
On Sun, Dec 23, 2018 at 10:57:02AM +0100, Michael Straube wrote: > This satisfies a checkpatch warning and is the preferred > method for notating the license. > > The SPDX identifier is a legally binding shorthand, which > can be used instead of the full boiler plate text. > > Signed-off-by: Michael Straube > --- > drivers/staging/mt29f_spinand/mt29f_spinand.c | 11 +-- > drivers/staging/mt29f_spinand/mt29f_spinand.h | 12 ++-- > 2 files changed, 3 insertions(+), 20 deletions(-) This driver is no longer in the kernel tree :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: define wilc_get_stats_async as static
On Thu, Jan 03, 2019 at 05:18:05PM +0100, Juan Manuel Torres Palma wrote: > Declare wilc_get_stats_async as static since it's only > used within the definition file scope. > > Signed-off-by: Juan Manuel Torres Palma > --- > drivers/staging/wilc1000/host_interface.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/wilc1000/host_interface.c > b/drivers/staging/wilc1000/host_interface.c > index 70c854d939ce..5dae6e7155d3 100644 > --- a/drivers/staging/wilc1000/host_interface.c > +++ b/drivers/staging/wilc1000/host_interface.c > @@ -1992,7 +1992,7 @@ int wilc_get_rssi(struct wilc_vif *vif, s8 *rssi_level) > return result; > } > > -int wilc_get_stats_async(struct wilc_vif *vif, struct rf_info *stats) > +static int wilc_get_stats_async(struct wilc_vif *vif, struct rf_info *stats) Someone else sent this same patch a few days before you did, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops
On Thu, Jan 03, 2019 at 09:23:57AM +0100, Sergio Paracuellos wrote: > On Thu, Jan 3, 2019 at 3:02 AM NeilBrown wrote: > > > > On Mon, Dec 31 2018, Sergio Paracuellos wrote: > > > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's > > > instead of redefine operations in the driver. Make use of them cleaning > > > a bit driver's code. > > > > > > Update DT accordly to make sure used bindings property in code match > > > with the board's DT bindings. > > > > > > Changes are only compile-tested. > > > > Thanks. This appears to work for me. > > It is awkward to test pinctrl changes because the firmware preconfigures > > all the pins, so the hardware will work correctly if pinctrl does > > nothing. > > So I change the dts file to mis-configure some pins for driving LEDs, > > and checked that the LEDs broken. The fixed the dts, and the LEDs > > started working again. > > I think that will have to do. > > > > Tested-by: NeilBrown > > > > Thanks, > > NeilBrown > > Cool! Thanks for testing and let me know. > > So, I sent this patch which solves a problem: > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html > > And this new patch is generated with that applied. Also this patch > solves the original problem > also and seems the way to go... Should be better to re-do this one > with all the fixed and reported by > tags added as a solution? > > What do you prefer, Greg? I'm sorry, but I do not understand. Is this 2 patch series not acceptable to merge? Should I drop it and use some other patch series? Should I ignore some other patch series? totally confused, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
