Re: [PATCH] Staging: comedi: ni_labpc_regs: fixed a block comment alignment issue
On 2017-06-07 19:31, Amisha Singh wrote: Fixed a coding style issue. Signed-off-by: Amisha Singh --- drivers/staging/comedi/drivers/ni_labpc_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/ni_labpc_regs.h b/drivers/staging/comedi/drivers/ni_labpc_regs.h index 8c52179..6003e9d 100644 --- a/drivers/staging/comedi/drivers/ni_labpc_regs.h +++ b/drivers/staging/comedi/drivers/ni_labpc_regs.h @@ -1,6 +1,6 @@ /* * ni_labpc register definitions. -*/ + */ #ifndef _NI_LABPC_REGS_H #define _NI_LABPC_REGS_H Thanks! Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/1] staging: vboxvideo: Add vboxvideo to drivers/staging
Hi All, Recently I've been working on cleaning up the vboxvideo driver with the intend of mainlining it. For more background info also see: http://hansdegoede.livejournal.com/17743.html Up until now this has never been done because of userspace ABI stability concerns surrounding the guest drivers. I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner. Why drivers/staging? This driver is already being patched into the kernel by several distros, thus it is good to get this driver upstream soon, so that work on the driver can be easily shared. At the same time we want to take our time to get this driver properly cleaned up before submitting it as a normal driver under drivers/gpu/drm, putting this driver in staging for now allows both. Note this driver has already been significantly cleaned up, when I started working on this the files under /usr/src/vboxguest/vboxvideo as installed by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681 lines. The version in this commit has 7275 lines. Of those 7275 lines 3980 lines are in an osindependent directory which contains portable code which is shared with other guest platforms such as C-structure definitions for the virtual graphics card protocol and helper functions for using these structures to communicate with the card. Since these files are shared they are in the standard Virtual Box upstream code style and not in the kernel coding style. All files outside of the osindependent directory fully adhere to the kernel coding style. Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vboxvideo: Add vboxvideo to drivers/staging
On Fri, Jun 09, 2017 at 11:58:31AM +0200, Hans de Goede wrote: > This commit adds the vboxvideo drm/kms driver for the virtual graphics > card used in Virtual Box virtual machines to drivers/staging. > > Why drivers/staging? This driver is already being patched into the kernel > by several distros, thus it is good to get this driver upstream soon, so > that work on the driver can be easily shared. Last time I looked, the user/kernel api was a horrid C++ structure mess, and I couldn't tease apart the needed pieces to get everything to even build properly. I'm glad to see this go in, but is that userspace api going to stay solid? What happens when we find bugs (and odds are, there are lots of them) with that api? Can I get some signed-off-by from teh virtual box developers here that they are ok with this work happening? Oh, and thanks a lot for pushing for this, I appreciate it, it's just that it seems too good to be true :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vboxvideo: Add vboxvideo to drivers/staging
Hi, On 09-06-17 12:07, Greg Kroah-Hartman wrote: On Fri, Jun 09, 2017 at 11:58:31AM +0200, Hans de Goede wrote: This commit adds the vboxvideo drm/kms driver for the virtual graphics card used in Virtual Box virtual machines to drivers/staging. Why drivers/staging? This driver is already being patched into the kernel by several distros, thus it is good to get this driver upstream soon, so that work on the driver can be easily shared. Last time I looked, the user/kernel api was a horrid C++ structure mess, and I couldn't tease apart the needed pieces to get everything to even build properly. I'm glad to see this go in, but is that userspace api going to stay solid? What happens when we find bugs (and odds are, there are lots of them) with that api? Note this submission is not the vboxguest driver, which has its own API (that is next on my todo list) this is just the drm/kms driver which only uses the standard drm/kms interfaces to userspace and nothing virtual box specific AFAIK. Sorry if I caused confusion with my: "Up until now this has never been done because of userspace ABI stability concerns surrounding the guest drivers. I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner." paragraph in the cover letter, that mostly applies to the vboxguest driver, which still needs a lot of work before I consider it even ready for staging. I guess that means I will get to answer your questions from above when I submit the vboxguest driver. All I can say for now is that we will need to deal with any userspace ABI bugs in case by case manner, while trying to maintain backward compatibility wherever possible. Can I get some signed-off-by from teh virtual box developers here that they are ok with this work happening? Michael, can you reply with your S-o-b please ? Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 3/6] netvsc: use typed pointer for internal state
Hello.
On 6/9/2017 2:21 AM, Stephen Hemminger wrote:
The element netvsc_device:extension is always a point to RNDIS
Pointer, maybe?
information.
Signed-off-by: Stephen Hemminger
---
drivers/net/hyperv/hyperv_net.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 262b2ea576a3..f82d54e0208c 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -763,8 +763,7 @@ struct netvsc_device {
refcount_t sc_offered;
- /* Holds rndis device info */
- void *extension;
+ struct rndis_device *extension;
int ring_size;
MBR, Sergei
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vboxvideo: Add vboxvideo to drivers/staging
Hello, 09.06.2017 12:21, Hans de Goede wrote: Hi, On 09-06-17 12:07, Greg Kroah-Hartman wrote: On Fri, Jun 09, 2017 at 11:58:31AM +0200, Hans de Goede wrote: This commit adds the vboxvideo drm/kms driver for the virtual graphics card used in Virtual Box virtual machines to drivers/staging. Why drivers/staging? This driver is already being patched into the kernel by several distros, thus it is good to get this driver upstream soon, so that work on the driver can be easily shared. Last time I looked, the user/kernel api was a horrid C++ structure mess, and I couldn't tease apart the needed pieces to get everything to even build properly. I'm glad to see this go in, but is that userspace api going to stay solid? What happens when we find bugs (and odds are, there are lots of them) with that api? Note this submission is not the vboxguest driver, which has its own API (that is next on my todo list) this is just the drm/kms driver which only uses the standard drm/kms interfaces to userspace and nothing virtual box specific AFAIK. I think that Greg is referring to the host kernel modules which implement our hypervisor. They do indeed require an exact match between driver and user-space. It does not apply to vboxguest. Sorry if I caused confusion with my: "Up until now this has never been done because of userspace ABI stability concerns surrounding the guest drivers. I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner." paragraph in the cover letter, that mostly applies to the vboxguest driver, which still needs a lot of work before I consider it even ready for staging. I guess that means I will get to answer your questions from above when I submit the vboxguest driver. All I can say for now is that we will need to deal with any userspace ABI bugs in case by case manner, while trying to maintain backward compatibility wherever possible. Can I get some signed-off-by from teh virtual box developers here that they are ok with this work happening? Michael, can you reply with your S-o-b please ? I haven't gone through your patch yet, but on the assumption that it matches what is in our repository plus the white-space changes you sent last night you have my signed-off-by. Is that enough, or would you like me to add it to the patch? A small comment regarding the Kconfig text - I would appreciate it if it mentioned why it is recommended to build it as a module - namely, so that the driver can be upgraded without upgrading the kernel (which makes sense in a virtual machine, where you often explicitly want to be running older software). And on the other hand, someone who doesn't need that might also appreciate knowing that it doesn't apply to them. Regards and thanks Michael Regards, Hans-- Michael Thayer | VirtualBox engineer ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vboxvideo: Add vboxvideo to drivers/staging
Hi, On 09-06-17 12:40, Michael Thayer wrote: Hello, 09.06.2017 12:21, Hans de Goede wrote: Hi, On 09-06-17 12:07, Greg Kroah-Hartman wrote: On Fri, Jun 09, 2017 at 11:58:31AM +0200, Hans de Goede wrote: This commit adds the vboxvideo drm/kms driver for the virtual graphics card used in Virtual Box virtual machines to drivers/staging. Why drivers/staging? This driver is already being patched into the kernel by several distros, thus it is good to get this driver upstream soon, so that work on the driver can be easily shared. Last time I looked, the user/kernel api was a horrid C++ structure mess, and I couldn't tease apart the needed pieces to get everything to even build properly. I'm glad to see this go in, but is that userspace api going to stay solid? What happens when we find bugs (and odds are, there are lots of them) with that api? Note this submission is not the vboxguest driver, which has its own API (that is next on my todo list) this is just the drm/kms driver which only uses the standard drm/kms interfaces to userspace and nothing virtual box specific AFAIK. I think that Greg is referring to the host kernel modules which implement our hypervisor. They do indeed require an exact match between driver and user-space. It does not apply to vboxguest. Ok. Sorry if I caused confusion with my: "Up until now this has never been done because of userspace ABI stability concerns surrounding the guest drivers. I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner." paragraph in the cover letter, that mostly applies to the vboxguest driver, which still needs a lot of work before I consider it even ready for staging. I guess that means I will get to answer your questions from above when I submit the vboxguest driver. All I can say for now is that we will need to deal with any userspace ABI bugs in case by case manner, while trying to maintain backward compatibility wherever possible. Can I get some signed-off-by from teh virtual box developers here that they are ok with this work happening? Michael, can you reply with your S-o-b please ? I haven't gone through your patch yet, but on the assumption that it matches what is in our repository plus the white-space changes you sent last night It matches what is currently in vbox upstream svn + the coding-style changes I sent + removing all #if LINUX_VERSION_CODE conditionals. you have my signed-off-by. Is that enough, or would you like me to add it to the patch? Replying to this mail with: "Signed-off-by: Michael Thayer " is enough. A small comment regarding the Kconfig text - I would appreciate it if it mentioned why it is recommended to build it as a module - namely, so that the driver can be upgraded without upgrading the kernel (which makes sense in a virtual machine, where you often explicitly want to be running older software). And on the other hand, someone who doesn't need that might also appreciate knowing that it doesn't apply to them. Ok I will update the text with a followup patch (or in v2 of this patch if a v2 is necessary). Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: speakup: Add missing blank line after declaration
This patch fixes checkpatch warnings about adding a blank line after
variable declaration.
Signed-off-by: Alexandre Ghiti
---
drivers/staging/speakup/main.c | 2 ++
drivers/staging/speakup/spk_ttyio.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index d2ad596..82e5de24 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1945,6 +1945,7 @@ static int handle_goto(struct vc_data *vc, u_char type,
u_char ch, u_short key)
goto oops;
if (ch == 8) {
u16 wch;
+
if (num == 0)
return -1;
wch = goto_buf[--num];
@@ -2287,6 +2288,7 @@ static int vt_notifier_call(struct notifier_block *nb,
speakup_bs(vc);
} else {
u16 d = param->c;
+
speakup_con_write(vc, &d, 1);
}
break;
diff --git a/drivers/staging/speakup/spk_ttyio.c
b/drivers/staging/speakup/spk_ttyio.c
index d55c056..4e34669 100644
--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -50,6 +50,7 @@ static int spk_ttyio_receive_buf2(struct tty_struct *tty,
if (spk_ttyio_synth->read_buff_add) {
int i;
+
for (i = 0; i < count; i++)
spk_ttyio_synth->read_buff_add(cp[i]);
@@ -162,6 +163,7 @@ static int spk_ttyio_out(struct spk_synth *in_synth, const
char ch)
{
if (in_synth->alive && speakup_tty && speakup_tty->ops->write) {
int ret = speakup_tty->ops->write(speakup_tty, &ch, 1);
+
if (ret == 0)
/* No room */
return 0;
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello
Hello My Dear , I came across your e-mail contact prior a private search while in need of your assistance. I am Aisha Al-Qaddafi, the only biological Daughter of Former President of Libya Col. Muammar Al-Qaddafi. Am a single Mother and a Widow with three Children. I have investment funds worth Eighteen Million Five Hundred Hundred Thousand United State Dollar ($18.500.000.00 ) and i need a trusted investment Manager/Partner because of my current refugee status, however, I am interested in you for investment project assistance in your country, may be from there, we can build business relationship in the nearest future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you more information about the investment funds. Best Regards Mrs Aisha Al-Qaddafi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 19/34] media: Add i.MX media core driver
On Wed, 2017-06-07 at 11:33 -0700, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
>
> Signed-off-by: Steve Longerbeam
>
> Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs.
>
> Signed-off-by: Philipp Zabel
>
> Add the bayer formats to imx-media's list of supported pixel and bus
> formats.
>
> Signed-off-by: Russell King
> ---
[...]
> diff --git a/drivers/staging/media/imx/imx-media-dev.c
> b/drivers/staging/media/imx/imx-media-dev.c
> new file mode 100644
> index 000..da694f6
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -0,0 +1,666 @@
[...]
> +/*
> + * adds given video device to given imx-media source pad vdev list.
> + * Continues upstream from the pad entity's sink pads.
> + */
> +static int imx_media_add_vdev_to_pad(struct imx_media_dev *imxmd,
> + struct imx_media_video_dev *vdev,
> + struct media_pad *srcpad)
> +{
> + struct media_entity *entity = srcpad->entity;
> + struct imx_media_subdev *imxsd;
> + struct imx_media_pad *imxpad;
> + struct media_link *link;
> + struct v4l2_subdev *sd;
> + int i, vdev_idx, ret;
> +
> + if (!is_media_entity_v4l2_subdev(entity))
> + return -EINVAL;
Could we make this return 0, to just skip non-v4l2_subdev entities?
Currently, imx_media_probe_complete silently fails with this -EINVAL if
there is a tvp5150 connected due to the separate media entities that the
tvp5150 driver creates for the input connectors (Composite0, for
example).
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 02/10] x86/hyper-v: stash the max number of virtual/logical processor
Max virtual processor will be needed for 'extended' hypercalls supporting
more than 64 vCPUs. While on it, unify on 'Hyper-V' in mshyperv.c as we
currently have a mix, report acquired misc features as well.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
arch/x86/include/asm/mshyperv.h | 2 ++
arch/x86/kernel/cpu/mshyperv.c | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 66f9f2ac..115a0e2 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -29,6 +29,8 @@ struct ms_hyperv_info {
u32 features;
u32 misc_features;
u32 hints;
+ u32 max_vp_index;
+ u32 max_lp_index;
};
extern struct ms_hyperv_info ms_hyperv;
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 04cb8d3..f259e01 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -175,9 +175,15 @@ static void __init ms_hyperv_init_platform(void)
ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES);
ms_hyperv.hints= cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
- pr_info("HyperV: features 0x%x, hints 0x%x\n",
+ pr_info("Hyper-V: features 0x%x, hints 0x%x\n",
ms_hyperv.features, ms_hyperv.hints);
+ ms_hyperv.max_vp_index = cpuid_eax(HVCPUID_IMPLEMENTATION_LIMITS);
+ ms_hyperv.max_lp_index = cpuid_ebx(HVCPUID_IMPLEMENTATION_LIMITS);
+
+ pr_debug("Hyper-V: max %u virtual processors, %u logical processors\n",
+ms_hyperv.max_vp_index, ms_hyperv.max_lp_index);
+
/*
* Extract host information.
*/
@@ -203,7 +209,7 @@ static void __init ms_hyperv_init_platform(void)
rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
hv_lapic_frequency = div_u64(hv_lapic_frequency, HZ);
lapic_timer_frequency = hv_lapic_frequency;
- pr_info("HyperV: LAPIC Timer Frequency: %#x\n",
+ pr_info("Hyper-V: LAPIC Timer Frequency: %#x\n",
lapic_timer_frequency);
}
@@ -237,7 +243,7 @@ static void __init ms_hyperv_init_platform(void)
}
const __refconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
- .name = "Microsoft HyperV",
+ .name = "Microsoft Hyper-V",
.detect = ms_hyperv_platform,
.init_platform = ms_hyperv_init_platform,
};
--
2.9.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements
Changes since v7: - Minor code style fixes (drop explicit casting, reformat code a bit) in PATCH3 and PATCH9 [Andy Shevchenko] Original description: Hyper-V supports hypercalls for doing local and remote TLB flushing and gives its guests hints when using hypercall is preferred. While doing hypercalls for local TLB flushes is probably not practical (and is not being suggested by modern Hyper-V versions) remote TLB flush with a hypercall brings significant improvement. To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I was creating 32 threads which were doing 10 mmap/munmaps each on some big file. Here are the results: Before: # time ./pthread_mmap ./randfile real3m33.118s user0m3.698s sys 3m16.624s After: # time ./pthread_mmap ./randfile real2m19.920s user0m2.662s sys 2m9.948s This series brings a number of small improvements along the way: fast hypercall implementation and using it for event signaling, rep hypercalls implementation, hyperv tracing subsystem (which only traces the newly added remote TLB flush for now). Vitaly Kuznetsov (10): x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set x86/hyper-v: stash the max number of virtual/logical processor x86/hyper-v: make hv_do_hypercall() inline x86/hyper-v: fast hypercall implementation hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT x86/hyper-v: implement rep hypercalls hyper-v: globalize vp_index x86/hyper-v: use hypercall for remote TLB flush x86/hyper-v: support extended CPU ranges for TLB flush hypercalls tracing/hyper-v: trace hyperv_mmu_flush_tlb_others() MAINTAINERS | 1 + arch/x86/Kbuild | 2 +- arch/x86/hyperv/Makefile| 2 +- arch/x86/hyperv/hv_init.c | 90 ++-- arch/x86/hyperv/mmu.c | 268 arch/x86/include/asm/mshyperv.h | 148 +++- arch/x86/include/asm/trace/hyperv.h | 38 + arch/x86/include/uapi/asm/hyperv.h | 17 +++ arch/x86/kernel/cpu/mshyperv.c | 13 +- drivers/hv/channel_mgmt.c | 20 +-- drivers/hv/connection.c | 7 +- drivers/hv/hv.c | 9 -- drivers/hv/hyperv_vmbus.h | 11 -- drivers/hv/vmbus_drv.c | 17 --- drivers/pci/host/pci-hyperv.c | 10 +- include/linux/hyperv.h | 17 +-- 16 files changed, 539 insertions(+), 131 deletions(-) create mode 100644 arch/x86/hyperv/mmu.c create mode 100644 arch/x86/include/asm/trace/hyperv.h -- 2.9.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 01/10] x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
Code is arch/x86/hyperv/ is only needed when CONFIG_HYPERV is set, the
'basic' support and detection lives in arch/x86/kernel/cpu/mshyperv.c
which is included when CONFIG_HYPERVISOR_GUEST is set.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
arch/x86/Kbuild | 2 +-
arch/x86/include/asm/mshyperv.h | 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index 586b786..3e6f640 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -8,7 +8,7 @@ obj-$(CONFIG_KVM) += kvm/
obj-$(CONFIG_XEN) += xen/
# Hyper-V paravirtualization support
-obj-$(CONFIG_HYPERVISOR_GUEST) += hyperv/
+obj-$(subst m,y,$(CONFIG_HYPERV)) += hyperv/
# lguest paravirtualization support
obj-$(CONFIG_LGUEST_GUEST) += lguest/
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 18325dc..66f9f2ac 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -174,7 +174,12 @@ void hyperv_init(void);
void hyperv_report_panic(struct pt_regs *regs);
bool hv_is_hypercall_page_setup(void);
void hyperv_cleanup(void);
-#endif
+#else /* CONFIG_HYPERV */
+static inline void hyperv_init(void) {}
+static inline bool hv_is_hypercall_page_setup(void) { return false; }
+static inline hyperv_cleanup(void) {}
+#endif /* CONFIG_HYPERV */
+
#ifdef CONFIG_HYPERV_TSCPAGE
struct ms_hyperv_tsc_page *hv_get_tsc_page(void);
static inline u64 hv_read_tsc_page(const struct ms_hyperv_tsc_page *tsc_pg)
--
2.9.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 03/10] x86/hyper-v: make hv_do_hypercall() inline
We have only three call sites for hv_do_hypercall() and we're going to
change HVCALL_SIGNAL_EVENT to doing fast hypercall so we can inline this
function for optimization.
Hyper-V top level functional specification states that r9-r11 registers
and flags may be clobbered by the hypervisor during hypercall and with
inlining this is somewhat important, add the clobbers.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
Changes since v7:
- Use U64_MAX instead of (u64)ULLONG_MAX [Andy Shevchenko]
---
arch/x86/hyperv/hv_init.c | 54 -
arch/x86/include/asm/mshyperv.h | 39 +
drivers/hv/connection.c | 2 ++
include/linux/hyperv.h | 1 -
4 files changed, 46 insertions(+), 50 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 5b882cc..691603e 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -75,7 +75,8 @@ static struct clocksource hyperv_cs_msr = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-static void *hypercall_pg;
+void *hv_hypercall_pg;
+EXPORT_SYMBOL_GPL(hv_hypercall_pg);
struct clocksource *hyperv_cs;
EXPORT_SYMBOL_GPL(hyperv_cs);
@@ -102,15 +103,15 @@ void hyperv_init(void)
guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
- hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
- if (hypercall_pg == NULL) {
+ hv_hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
+ if (hv_hypercall_pg == NULL) {
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
return;
}
rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
hypercall_msr.enable = 1;
- hypercall_msr.guest_physical_address = vmalloc_to_pfn(hypercall_pg);
+ hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
/*
@@ -170,51 +171,6 @@ void hyperv_cleanup(void)
}
EXPORT_SYMBOL_GPL(hyperv_cleanup);
-/*
- * hv_do_hypercall- Invoke the specified hypercall
- */
-u64 hv_do_hypercall(u64 control, void *input, void *output)
-{
- u64 input_address = (input) ? virt_to_phys(input) : 0;
- u64 output_address = (output) ? virt_to_phys(output) : 0;
-#ifdef CONFIG_X86_64
- u64 hv_status = 0;
-
- if (!hypercall_pg)
- return (u64)ULLONG_MAX;
-
- __asm__ __volatile__("mov %0, %%r8" : : "r" (output_address) : "r8");
- __asm__ __volatile__("call *%3" : "=a" (hv_status) :
-"c" (control), "d" (input_address),
-"m" (hypercall_pg));
-
- return hv_status;
-
-#else
-
- u32 control_hi = control >> 32;
- u32 control_lo = control & 0x;
- u32 hv_status_hi = 1;
- u32 hv_status_lo = 1;
- u32 input_address_hi = input_address >> 32;
- u32 input_address_lo = input_address & 0x;
- u32 output_address_hi = output_address >> 32;
- u32 output_address_lo = output_address & 0x;
-
- if (!hypercall_pg)
- return (u64)ULLONG_MAX;
-
- __asm__ __volatile__ ("call *%8" : "=d"(hv_status_hi),
- "=a"(hv_status_lo) : "d" (control_hi),
- "a" (control_lo), "b" (input_address_hi),
- "c" (input_address_lo), "D"(output_address_hi),
- "S"(output_address_lo), "m" (hypercall_pg));
-
- return hv_status_lo | ((u64)hv_status_hi << 32);
-#endif /* !x86_64 */
-}
-EXPORT_SYMBOL_GPL(hv_do_hypercall);
-
void hyperv_report_panic(struct pt_regs *regs)
{
static bool panic_reported;
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 115a0e2..a004b3b 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -171,6 +171,45 @@ void hv_remove_crash_handler(void);
#if IS_ENABLED(CONFIG_HYPERV)
extern struct clocksource *hyperv_cs;
+extern void *hv_hypercall_pg;
+
+static inline u64 hv_do_hypercall(u64 control, void *input, void *output)
+{
+ u64 input_address = input ? virt_to_phys(input) : 0;
+ u64 output_address = output ? virt_to_phys(output) : 0;
+ u64 hv_status;
+ register void *__sp asm(_ASM_SP);
+
+#ifdef CONFIG_X86_64
+ if (!hv_hypercall_pg)
+ return U64_MAX;
+
+ __asm__ __volatile__("mov %4, %%r8\n"
+"call *%5"
+: "=a" (hv_status), "+r" (__sp),
+ "+c" (control), "+d" (input_address)
+: "r" (output_address), "m" (hv_hypercall_pg)
+: "cc", "memory", "r8", "r9", "r10", "r11");
+#else
+ u32 input_address_hi = upper_32_bits(input_address);
+ u32 input_address_lo = lower_32_bits(input_add
[PATCH v8 05/10] hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
We need to pass only 8 bytes of input for HvSignalEvent which makes it a
perfect fit for fast hypercall. hv_input_signal_event_buffer is not needed
any more and hv_input_signal_event is converted to union for convenience.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
drivers/hv/channel_mgmt.c | 13 ++---
drivers/hv/connection.c | 2 +-
include/linux/hyperv.h| 15 +--
3 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0fabd41..f501ce1 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -806,21 +806,12 @@ static void vmbus_onoffer(struct
vmbus_channel_message_header *hdr)
/*
* Setup state for signalling the host.
*/
- newchannel->sig_event = (struct hv_input_signal_event *)
- (ALIGN((unsigned long)
- &newchannel->sig_buf,
- HV_HYPERCALL_PARAM_ALIGN));
-
- newchannel->sig_event->connectionid.asu32 = 0;
- newchannel->sig_event->connectionid.u.id = VMBUS_EVENT_CONNECTION_ID;
- newchannel->sig_event->flag_number = 0;
- newchannel->sig_event->rsvdz = 0;
+ newchannel->sig_event = VMBUS_EVENT_CONNECTION_ID;
if (vmbus_proto_version != VERSION_WS2008) {
newchannel->is_dedicated_interrupt =
(offer->is_dedicated_interrupt != 0);
- newchannel->sig_event->connectionid.u.id =
- offer->connection_id;
+ newchannel->sig_event = offer->connection_id;
}
memcpy(&newchannel->offermsg, offer,
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 45e806e..37ecf51 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -408,6 +408,6 @@ void vmbus_set_event(struct vmbus_channel *channel)
if (!channel->is_dedicated_interrupt)
vmbus_send_interrupt(child_relid);
- hv_do_hypercall(HVCALL_SIGNAL_EVENT, channel->sig_event, NULL);
+ hv_do_fast_hypercall8(HVCALL_SIGNAL_EVENT, channel->sig_event);
}
EXPORT_SYMBOL_GPL(vmbus_set_event);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index d1ae02d..2c9a2c8 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -677,18 +677,6 @@ union hv_connection_id {
} u;
};
-/* Definition of the hv_signal_event hypercall input structure. */
-struct hv_input_signal_event {
- union hv_connection_id connectionid;
- u16 flag_number;
- u16 rsvdz;
-};
-
-struct hv_input_signal_event_buffer {
- u64 align8;
- struct hv_input_signal_event event;
-};
-
enum hv_numa_policy {
HV_BALANCED = 0,
HV_LOCALIZED,
@@ -771,8 +759,7 @@ struct vmbus_channel {
} callback_mode;
bool is_dedicated_interrupt;
- struct hv_input_signal_event_buffer sig_buf;
- struct hv_input_signal_event *sig_event;
+ u64 sig_event;
/*
* Starting with win8, this field will be used to specify
--
2.9.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 04/10] x86/hyper-v: fast hypercall implementation
Hyper-V supports 'fast' hypercalls when all parameters are passed through
registers. Implement an inline version of a simpliest of these calls:
hypercall with one 8-byte input and no output.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
arch/x86/include/asm/mshyperv.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index a004b3b..f3bedb4 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -211,6 +211,40 @@ static inline u64 hv_do_hypercall(u64 control, void
*input, void *output)
return hv_status;
}
+#define HV_HYPERCALL_FAST_BIT BIT(16)
+
+/* Fast hypercall with 8 bytes of input and no output */
+static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
+{
+ u64 hv_status, control = (u64)code | HV_HYPERCALL_FAST_BIT;
+ register void *__sp asm(_ASM_SP);
+
+#ifdef CONFIG_X86_64
+ {
+ __asm__ __volatile__("call *%4"
+: "=a" (hv_status), "+r" (__sp),
+ "+c" (control), "+d" (input1)
+: "m" (hv_hypercall_pg)
+: "cc", "r8", "r9", "r10", "r11");
+ }
+#else
+ {
+ u32 input1_hi = upper_32_bits(input1);
+ u32 input1_lo = lower_32_bits(input1);
+
+ __asm__ __volatile__ ("call *%5"
+ : "=A"(hv_status),
+ "+c"(input1_lo),
+ "+r"(__sp)
+ : "A" (control),
+ "b" (input1_hi),
+ "m" (hv_hypercall_pg)
+ : "cc", "edi", "esi");
+ }
+#endif
+ return hv_status;
+}
+
void hyperv_init(void);
void hyperv_report_panic(struct pt_regs *regs);
bool hv_is_hypercall_page_setup(void);
--
2.9.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 07/10] hyper-v: globalize vp_index
To support implementing remote TLB flushing on Hyper-V with a hypercall
we need to make vp_index available outside of vmbus module. Rename and
globalize.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
arch/x86/hyperv/hv_init.c | 34 +-
arch/x86/include/asm/mshyperv.h | 24
drivers/hv/channel_mgmt.c | 7 +++
drivers/hv/connection.c | 3 ++-
drivers/hv/hv.c | 9 -
drivers/hv/hyperv_vmbus.h | 11 ---
drivers/hv/vmbus_drv.c | 17 -
drivers/pci/host/pci-hyperv.c | 10 +-
include/linux/hyperv.h | 1 -
9 files changed, 67 insertions(+), 49 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 691603e..e93b9a0 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
#ifdef CONFIG_HYPERV_TSCPAGE
@@ -80,6 +82,20 @@ EXPORT_SYMBOL_GPL(hv_hypercall_pg);
struct clocksource *hyperv_cs;
EXPORT_SYMBOL_GPL(hyperv_cs);
+u32 *hv_vp_index;
+EXPORT_SYMBOL_GPL(hv_vp_index);
+
+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;
+
+ return 0;
+}
+
/*
* This function is to be invoked early in the boot sequence after the
* hypervisor has been detected.
@@ -95,6 +111,16 @@ void hyperv_init(void)
if (x86_hyper != &x86_hyper_ms_hyperv)
return;
+ /* Allocate percpu VP index */
+ hv_vp_index = kmalloc_array(num_possible_cpus(), sizeof(*hv_vp_index),
+ GFP_KERNEL);
+ if (!hv_vp_index)
+ return;
+
+ if (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/hyperv_init:online",
+ hv_cpu_init, NULL) < 0)
+ goto free_vp_index;
+
/*
* Setup the hypercall page and enable hypercalls.
* 1. Register the guest ID
@@ -106,7 +132,7 @@ void hyperv_init(void)
hv_hypercall_pg = __vmalloc(PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL_RX);
if (hv_hypercall_pg == NULL) {
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
- return;
+ goto free_vp_index;
}
rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
@@ -149,6 +175,12 @@ void hyperv_init(void)
hyperv_cs = &hyperv_cs_msr;
if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
clocksource_register_hz(&hyperv_cs_msr, NSEC_PER_SEC/100);
+
+ return;
+
+free_vp_index:
+ kfree(hv_vp_index);
+ hv_vp_index = NULL;
}
/*
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ed8107d..7581251 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -284,6 +284,30 @@ static inline u64 hv_do_rep_hypercall(u16 code, u16
rep_count, u16 varhead_size,
return status;
}
+/*
+ * Hypervisor's notion of virtual processor ID is different from
+ * Linux' notion of CPU ID. This information can only be retrieved
+ * in the context of the calling CPU. Setup a map for easy access
+ * to this information.
+ */
+extern u32 *hv_vp_index;
+
+/**
+ * hv_cpu_number_to_vp_number() - Map CPU to VP.
+ * @cpu_number: CPU number in Linux terms
+ *
+ * This function returns the mapping between the Linux processor
+ * number and the hypervisor's virtual processor number, useful
+ * in making hypercalls and such that talk about specific
+ * processors.
+ *
+ * Return: Virtual processor number in Hyper-V terms
+ */
+static inline int hv_cpu_number_to_vp_number(int cpu_number)
+{
+ return hv_vp_index[cpu_number];
+}
+
void hyperv_init(void);
void hyperv_report_panic(struct pt_regs *regs);
bool hv_is_hypercall_page_setup(void);
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index f501ce1..331b314 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -600,7 +600,7 @@ static void init_vp_index(struct vmbus_channel *channel,
u16 dev_type)
*/
channel->numa_node = 0;
channel->target_cpu = 0;
- channel->target_vp = hv_context.vp_index[0];
+ channel->target_vp = hv_cpu_number_to_vp_number(0);
return;
}
@@ -684,7 +684,7 @@ static void init_vp_index(struct vmbus_channel *channel,
u16 dev_type)
}
channel->target_cpu = cur_cpu;
- channel->target_vp = hv_context.vp_index[cur_cpu];
+ channel->target_vp = hv_cpu_number_to_vp_number(cur_cpu);
}
static void vmbus_wait_for_unload(void)
@@ -1220,8 +1220,7 @@ struct vmbus_channel *vmbus_get_outgoing_channel(struct
vmbus_channel *primary)
return outgoing_channel;
}
- cur_cpu = hv_context.vp_index[get_cpu()];
- put_cpu(
[PATCH v8 06/10] x86/hyper-v: implement rep hypercalls
Rep hypercalls are normal hypercalls which perform multiple actions at
once. Hyper-V guarantees to return exectution to the caller in not more
than 50us and the caller needs to use hypercall continuation. Touch NMI
watchdog between hypercall invocations.
This is going to be used for HvFlushVirtualAddressList hypercall for
remote TLB flushing.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Andy Shevchenko
---
arch/x86/include/asm/mshyperv.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index f3bedb4..ed8107d 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
/*
@@ -211,7 +212,13 @@ static inline u64 hv_do_hypercall(u64 control, void
*input, void *output)
return hv_status;
}
+#define HV_HYPERCALL_RESULT_MASK GENMASK_ULL(15, 0)
#define HV_HYPERCALL_FAST_BIT BIT(16)
+#define HV_HYPERCALL_VARHEAD_OFFSET17
+#define HV_HYPERCALL_REP_COMP_OFFSET 32
+#define HV_HYPERCALL_REP_COMP_MASK GENMASK_ULL(43, 32)
+#define HV_HYPERCALL_REP_START_OFFSET 48
+#define HV_HYPERCALL_REP_START_MASKGENMASK_ULL(59, 48)
/* Fast hypercall with 8 bytes of input and no output */
static inline u64 hv_do_fast_hypercall8(u16 code, u64 input1)
@@ -245,6 +252,38 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64
input1)
return hv_status;
}
+/*
+ * Rep hypercalls. Callers of this functions are supposed to ensure that
+ * rep_count and varhead_size comply with Hyper-V hypercall definition.
+ */
+static inline u64 hv_do_rep_hypercall(u16 code, u16 rep_count, u16
varhead_size,
+ void *input, void *output)
+{
+ u64 control = code;
+ u64 status;
+ u16 rep_comp;
+
+ control |= (u64)varhead_size << HV_HYPERCALL_VARHEAD_OFFSET;
+ control |= (u64)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
+
+ do {
+ status = hv_do_hypercall(control, input, output);
+ if ((status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS)
+ return status;
+
+ /* Bits 32-43 of status have 'Reps completed' data. */
+ rep_comp = (status & HV_HYPERCALL_REP_COMP_MASK) >>
+ HV_HYPERCALL_REP_COMP_OFFSET;
+
+ control &= ~HV_HYPERCALL_REP_START_MASK;
+ control |= (u64)rep_comp << HV_HYPERCALL_REP_START_OFFSET;
+
+ touch_nmi_watchdog();
+ } while (rep_comp < rep_count);
+
+ return status;
+}
+
void hyperv_init(void);
void hyperv_report_panic(struct pt_regs *regs);
bool hv_is_hypercall_page_setup(void);
--
2.9.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v8 08/10] x86/hyper-v: use hypercall for remote TLB flush
Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
this is supposed to work faster than IPIs.
Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls
we need to put the input somewhere in memory and we don't really want to
have memory allocation on each call so we pre-allocate per cpu memory areas
on boot.
pv_ops patching is happening very early so we need to separate
hyperv_setup_mmu_ops() and hyper_alloc_mmu().
It is possible and easy to implement local TLB flushing too and there is
even a hint for that. However, I don't see a room for optimization on the
host side as both hypercall and native tlb flush will result in vmexit. The
hint is also not set on modern Hyper-V versions.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/hyperv/Makefile | 2 +-
arch/x86/hyperv/hv_init.c | 2 +
arch/x86/hyperv/mmu.c | 135 +
arch/x86/include/asm/mshyperv.h| 3 +
arch/x86/include/uapi/asm/hyperv.h | 7 ++
arch/x86/kernel/cpu/mshyperv.c | 1 +
6 files changed, 149 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/hyperv/mmu.c
diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index 171ae09..367a820 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1 +1 @@
-obj-y := hv_init.o
+obj-y := hv_init.o mmu.o
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index e93b9a0..1a8eb55 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -140,6 +140,8 @@ void hyperv_init(void)
hypercall_msr.guest_physical_address = vmalloc_to_pfn(hv_hypercall_pg);
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+ hyper_alloc_mmu();
+
/*
* Register Hyper-V specific clocksource.
*/
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
new file mode 100644
index 000..fe87ffe
--- /dev/null
+++ b/arch/x86/hyperv/mmu.c
@@ -0,0 +1,135 @@
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
+struct hv_flush_pcpu {
+ u64 address_space;
+ u64 flags;
+ u64 processor_mask;
+ u64 gva_list[];
+};
+
+/* Each gva in gva_list encodes up to 4096 pages to flush */
+#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
+
+static struct hv_flush_pcpu __percpu *pcpu_flush;
+
+/*
+ * Fills in gva_list starting from offset. Returns the number of items filled
+ * in gva_list (including offset)
+ */
+static inline int fill_gva_list(u64 gva_list[], int offset,
+ unsigned long start, unsigned long end)
+{
+ int gva_n = offset;
+ unsigned long cur = start, diff;
+
+ do {
+ diff = end > cur ? end - cur : 0;
+
+ gva_list[gva_n] = cur & PAGE_MASK;
+ /*
+* Lower 12 bits encode the number of additional
+* pages to flush (in addition to the 'cur' page).
+*/
+ if (diff >= HV_TLB_FLUSH_UNIT)
+ gva_list[gva_n] |= ~PAGE_MASK;
+ else if (diff)
+ gva_list[gva_n] |= (diff - 1) >> PAGE_SHIFT;
+
+ cur += HV_TLB_FLUSH_UNIT;
+ gva_n++;
+
+ } while (cur < end);
+
+ return gva_n;
+}
+
+static void hyperv_flush_tlb_others(const struct cpumask *cpus,
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end)
+{
+ int cpu, vcpu, gva_n, max_gvas;
+ struct hv_flush_pcpu *flush;
+ u64 status = U64_MAX;
+ unsigned long flags;
+
+ if (!pcpu_flush || !hv_hypercall_pg)
+ goto do_native;
+
+ if (cpumask_empty(cpus))
+ return;
+
+ local_irq_save(flags);
+
+ flush = this_cpu_ptr(pcpu_flush);
+
+ if (mm) {
+ flush->address_space = virt_to_phys(mm->pgd);
+ flush->flags = 0;
+ } else {
+ flush->address_space = 0;
+ flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+ }
+
+ flush->processor_mask = 0;
+ if (cpumask_equal(cpus, cpu_present_mask)) {
+ flush->flags |= HV_FLUSH_ALL_PROCESSORS;
+ } else {
+ for_each_cpu(cpu, cpus) {
+ vcpu = hv_cpu_number_to_vp_number(cpu);
+ if (vcpu < 64)
+ __set_bit(vcpu, (unsigned long *)
+ &flush->processor_mask);
+ else
+ goto do_native;
+ }
+ }
+
+ /*
+* We can flush not more than max_gvas with one hypercall. Flush the
+* whole address space if we were asked to do more.
+*/
+ max_gvas = (PAGE_SIZE - sizeof(*flush)) / sizeof(flush->gva
[PATCH v8 09/10] x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
Hyper-V hosts may support more than 64 vCPUs, we need to use
HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX/LIST_EX hypercalls in this
case.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v7:
- Drop explicit casting from virt_to_phys() [Andy Shevchenko]
- Re-format max_gvas calculus [Andy Shevchenko]
---
arch/x86/hyperv/mmu.c | 130 -
arch/x86/include/uapi/asm/hyperv.h | 10 +++
2 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index fe87ffe..0712111 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -16,11 +16,25 @@ struct hv_flush_pcpu {
u64 gva_list[];
};
+/* HvFlushVirtualAddressSpaceEx, HvFlushVirtualAddressListEx hypercalls */
+struct hv_flush_pcpu_ex {
+ u64 address_space;
+ u64 flags;
+ struct {
+ u64 format;
+ u64 valid_bank_mask;
+ u64 bank_contents[];
+ } hv_vp_set;
+ u64 gva_list[];
+};
+
/* Each gva in gva_list encodes up to 4096 pages to flush */
#define HV_TLB_FLUSH_UNIT (4096 * PAGE_SIZE)
static struct hv_flush_pcpu __percpu *pcpu_flush;
+static struct hv_flush_pcpu_ex __percpu *pcpu_flush_ex;
+
/*
* Fills in gva_list starting from offset. Returns the number of items filled
* in gva_list (including offset)
@@ -52,6 +66,34 @@ static inline int fill_gva_list(u64 gva_list[], int offset,
return gva_n;
}
+/* Return the number of banks in the resulting vp_set */
+static inline int cpumask_to_vp_set(struct hv_flush_pcpu_ex *flush,
+ const struct cpumask *cpus)
+{
+ int cpu, vcpu, vcpu_bank, vcpu_offset, nr_bank = 1;
+
+ /*
+* Some banks may end up being empty but this is acceptable.
+*/
+ for_each_cpu(cpu, cpus) {
+ vcpu = hv_cpu_number_to_vp_number(cpu);
+ vcpu_bank = vcpu / 64;
+ vcpu_offset = vcpu % 64;
+
+ /* valid_bank_mask can represent up to 64 banks */
+ if (vcpu_bank >= 64)
+ return 0;
+
+ __set_bit(vcpu_offset, (unsigned long *)
+ &flush->hv_vp_set.bank_contents[vcpu_bank]);
+ if (vcpu_bank >= nr_bank)
+ nr_bank = vcpu_bank + 1;
+ }
+ flush->hv_vp_set.valid_bank_mask = GENMASK_ULL(nr_bank - 1, 0);
+
+ return nr_bank;
+}
+
static void hyperv_flush_tlb_others(const struct cpumask *cpus,
struct mm_struct *mm, unsigned long start,
unsigned long end)
@@ -120,16 +162,100 @@ static void hyperv_flush_tlb_others(const struct cpumask
*cpus,
native_flush_tlb_others(cpus, mm, start, end);
}
+static void hyperv_flush_tlb_others_ex(const struct cpumask *cpus,
+ struct mm_struct *mm,
+ unsigned long start,
+ unsigned long end)
+{
+ int nr_bank = 0, max_gvas, gva_n;
+ struct hv_flush_pcpu_ex *flush;
+ u64 status = U64_MAX;
+ unsigned long flags;
+
+ if (!pcpu_flush_ex || !hv_hypercall_pg)
+ goto do_native;
+
+ if (cpumask_empty(cpus))
+ return;
+
+ local_irq_save(flags);
+
+ flush = this_cpu_ptr(pcpu_flush_ex);
+
+ if (mm) {
+ flush->address_space = virt_to_phys(mm->pgd);
+ flush->flags = 0;
+ } else {
+ flush->address_space = 0;
+ flush->flags = HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES;
+ }
+
+ flush->hv_vp_set.valid_bank_mask = 0;
+
+ if (!cpumask_equal(cpus, cpu_present_mask)) {
+ flush->hv_vp_set.format = HV_GENERIC_SET_SPARCE_4K;
+ nr_bank = cpumask_to_vp_set(flush, cpus);
+ }
+
+ if (!nr_bank) {
+ flush->hv_vp_set.format = HV_GENERIC_SET_ALL;
+ flush->flags |= HV_FLUSH_ALL_PROCESSORS;
+ }
+
+ /*
+* We can flush not more than max_gvas with one hypercall. Flush the
+* whole address space if we were asked to do more.
+*/
+ max_gvas =
+ (PAGE_SIZE - sizeof(*flush) - nr_bank *
+sizeof(flush->hv_vp_set.bank_contents[0])) /
+ sizeof(flush->gva_list[0]);
+
+ if (end == TLB_FLUSH_ALL) {
+ flush->flags |= HV_FLUSH_NON_GLOBAL_MAPPINGS_ONLY;
+ status = hv_do_rep_hypercall(
+ HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
+ 0, nr_bank + 2, flush, NULL);
+ } else if (end && ((end - start)/HV_TLB_FLUSH_UNIT) > max_gvas) {
+ status = hv_do_rep_hypercall(
+ HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX,
+ 0, nr_bank + 2, flush, NULL);
+ } else {
+ gva_n = fill_gva_list(flush->gva_list, nr_bank, start,
[PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
Tracing is done the same way we do xen_mmu_flush_tlb_others().
Signed-off-by: Vitaly Kuznetsov
---
MAINTAINERS | 1 +
arch/x86/hyperv/mmu.c | 7 +++
arch/x86/include/asm/trace/hyperv.h | 38 +
3 files changed, 46 insertions(+)
create mode 100644 arch/x86/include/asm/trace/hyperv.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e3f44fd..001614b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6168,6 +6168,7 @@ M:Stephen Hemminger
L: de...@linuxdriverproject.org
S: Maintained
F: arch/x86/include/asm/mshyperv.h
+F: arch/x86/include/asm/trace/hyperv.h
F: arch/x86/include/uapi/asm/hyperv.h
F: arch/x86/kernel/cpu/mshyperv.c
F: arch/x86/hyperv
diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
index 0712111..cb35453 100644
--- a/arch/x86/hyperv/mmu.c
+++ b/arch/x86/hyperv/mmu.c
@@ -8,6 +8,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include
+
/* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
struct hv_flush_pcpu {
u64 address_space;
@@ -103,6 +106,8 @@ static void hyperv_flush_tlb_others(const struct cpumask
*cpus,
u64 status = U64_MAX;
unsigned long flags;
+ trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
+
if (!pcpu_flush || !hv_hypercall_pg)
goto do_native;
@@ -172,6 +177,8 @@ static void hyperv_flush_tlb_others_ex(const struct cpumask
*cpus,
u64 status = U64_MAX;
unsigned long flags;
+ trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
+
if (!pcpu_flush_ex || !hv_hypercall_pg)
goto do_native;
diff --git a/arch/x86/include/asm/trace/hyperv.h
b/arch/x86/include/asm/trace/hyperv.h
new file mode 100644
index 000..e44ece1
--- /dev/null
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -0,0 +1,38 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM hyperv
+
+#if !defined(_TRACE_HYPERV_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_HYPERV_H
+
+#include
+
+#if IS_ENABLED(CONFIG_HYPERV)
+
+TRACE_EVENT(hyperv_mmu_flush_tlb_others,
+ TP_PROTO(const struct cpumask *cpus, struct mm_struct *mm,
+unsigned long addr, unsigned long end),
+ TP_ARGS(cpus, mm, addr, end),
+ TP_STRUCT__entry(
+ __field(unsigned int, ncpus)
+ __field(struct mm_struct *, mm)
+ __field(unsigned long, addr)
+ __field(unsigned long, end)
+ ),
+ TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
+ __entry->mm = mm;
+ __entry->addr = addr,
+ __entry->end = end),
+ TP_printk("ncpus %d mm %p addr %lx, end %lx",
+ __entry->ncpus, __entry->mm, __entry->addr, __entry->end)
+ );
+
+#endif /* CONFIG_HYPERV */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH asm/trace/
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE hyperv
+#endif /* _TRACE_HYPERV_H */
+
+/* This part must be outside protection */
+#include
--
2.9.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: llite: Make structure describing various file operations 'const'
Use 'const' in declarations of various 'file_operations' structures.
Signed-off-by: Roman Storozhenko
---
drivers/staging/lustre/lustre/llite/file.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index 67c4b9c..4072240 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -3114,7 +3114,7 @@ int ll_inode_permission(struct inode *inode, int mask)
}
/* -o localflock - only provides locally consistent flock locks */
-struct file_operations ll_file_operations = {
+struct const file_operations ll_file_operations = {
.read_iter = ll_file_read_iter,
.write_iter = ll_file_write_iter,
.unlocked_ioctl = ll_file_ioctl,
@@ -3127,7 +3127,7 @@ struct file_operations ll_file_operations = {
.flush= ll_flush
};
-struct file_operations ll_file_operations_flock = {
+struct const file_operations ll_file_operations_flock = {
.read_iter= ll_file_read_iter,
.write_iter = ll_file_write_iter,
.unlocked_ioctl = ll_file_ioctl,
@@ -3143,7 +3143,7 @@ struct file_operations ll_file_operations_flock = {
};
/* These are for -o noflock - to return ENOSYS on flock calls */
-struct file_operations ll_file_operations_noflock = {
+struct const file_operations ll_file_operations_noflock = {
.read_iter= ll_file_read_iter,
.write_iter = ll_file_write_iter,
.unlocked_ioctl = ll_file_ioctl,
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: fid: Fixes debug output style problem
Fixes a style problems. Replaces non-standard 'Lx' specifier with a standard 'llx'. Signed-off-by: Roman Storozhenko --- drivers/staging/lustre/lustre/fid/fid_request.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/fid/fid_request.c b/drivers/staging/lustre/lustre/fid/fid_request.c index 999f250..cd84b42 100644 --- a/drivers/staging/lustre/lustre/fid/fid_request.c +++ b/drivers/staging/lustre/lustre/fid/fid_request.c @@ -259,7 +259,7 @@ int seq_client_alloc_fid(const struct lu_env *env, return rc; } - CDEBUG(D_INFO, "%s: Switch to sequence [0x%16.16Lx]\n", + CDEBUG(D_INFO, "%s: Switch to sequence [0x%16.16llx]\n", seq->lcs_name, seqnr); seq->lcs_fid.f_oid = LUSTRE_FID_INIT_OID; -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] Drivers: unisys: visorhba - style fix
> -Original Message-
> From: Derek Robson [mailto:robso...@gmail.com]
> Sent: Friday, June 9, 2017 1:16 AM
> To: Kershner, David A ;
> gre...@linuxfoundation.org; Binder, David Anthony
> ; Sell, Timothy C ;
> Wadgaonkar, Sameer Laxmikant ;
> Thompson, Bryan E. ; robso...@gmail.com
> Cc: *S-Par-Maintainer ;
> de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] Drivers: unisys: visorhba - style fix
>
> Fixed style of permissions to octal.
> Found using checkpatch
>
> Signed-off-by: Derek Robson
Acked-by: David Kershner
> ---
> drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
> b/drivers/staging/unisys/visorhba/visorhba_main.c
> index 2fd31c9762c6..a6e7a6bbc428 100644
> --- a/drivers/staging/unisys/visorhba/visorhba_main.c
> +++ b/drivers/staging/unisys/visorhba/visorhba_main.c
> @@ -1090,7 +1090,7 @@ static int visorhba_probe(struct visor_device *dev)
> goto err_scsi_remove_host;
> }
> devdata->debugfs_info =
> - debugfs_create_file("info", S_IRUSR | S_IRGRP,
> + debugfs_create_file("info", 0440,
> devdata->debugfs_dir, devdata,
> &info_debugfs_fops);
> if (!devdata->debugfs_info) {
> --
> 2.13.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements
On Fri, Jun 9, 2017 at 4:27 PM, Vitaly Kuznetsov wrote: > Changes since v7: > - Minor code style fixes (drop explicit casting, reformat code a bit) > in PATCH3 and PATCH9 [Andy Shevchenko] > > Original description: > > Hyper-V supports hypercalls for doing local and remote TLB flushing and > gives its guests hints when using hypercall is preferred. While doing > hypercalls for local TLB flushes is probably not practical (and is not > being suggested by modern Hyper-V versions) remote TLB flush with a > hypercall brings significant improvement. > > To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I > was creating 32 threads which were doing 10 mmap/munmaps each on some > big file. Here are the results: > > Before: > # time ./pthread_mmap ./randfile > real3m33.118s > user0m3.698s > sys 3m16.624s > > After: > # time ./pthread_mmap ./randfile > real2m19.920s > user0m2.662s > sys 2m9.948s > > This series brings a number of small improvements along the way: fast > hypercall implementation and using it for event signaling, rep hypercalls > implementation, hyperv tracing subsystem (which only traces the newly added > remote TLB flush for now). > FWIW, Reviewed-by: Andy Shevchenko to the patches that do not have it yet. > Vitaly Kuznetsov (10): > x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set > x86/hyper-v: stash the max number of virtual/logical processor > x86/hyper-v: make hv_do_hypercall() inline > x86/hyper-v: fast hypercall implementation > hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT > x86/hyper-v: implement rep hypercalls > hyper-v: globalize vp_index > x86/hyper-v: use hypercall for remote TLB flush > x86/hyper-v: support extended CPU ranges for TLB flush hypercalls > tracing/hyper-v: trace hyperv_mmu_flush_tlb_others() > > MAINTAINERS | 1 + > arch/x86/Kbuild | 2 +- > arch/x86/hyperv/Makefile| 2 +- > arch/x86/hyperv/hv_init.c | 90 ++-- > arch/x86/hyperv/mmu.c | 268 > > arch/x86/include/asm/mshyperv.h | 148 +++- > arch/x86/include/asm/trace/hyperv.h | 38 + > arch/x86/include/uapi/asm/hyperv.h | 17 +++ > arch/x86/kernel/cpu/mshyperv.c | 13 +- > drivers/hv/channel_mgmt.c | 20 +-- > drivers/hv/connection.c | 7 +- > drivers/hv/hv.c | 9 -- > drivers/hv/hyperv_vmbus.h | 11 -- > drivers/hv/vmbus_drv.c | 17 --- > drivers/pci/host/pci-hyperv.c | 10 +- > include/linux/hyperv.h | 17 +-- > 16 files changed, 539 insertions(+), 131 deletions(-) > create mode 100644 arch/x86/hyperv/mmu.c > create mode 100644 arch/x86/include/asm/trace/hyperv.h > > -- > 2.9.4 > -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements
On Fri, 9 Jun 2017 15:27:26 +0200 Vitaly Kuznetsov wrote: > Changes since v7: > - Minor code style fixes (drop explicit casting, reformat code a bit) > in PATCH3 and PATCH9 [Andy Shevchenko] > > Original description: > > Hyper-V supports hypercalls for doing local and remote TLB flushing and > gives its guests hints when using hypercall is preferred. While doing > hypercalls for local TLB flushes is probably not practical (and is not > being suggested by modern Hyper-V versions) remote TLB flush with a > hypercall brings significant improvement. > > To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I > was creating 32 threads which were doing 10 mmap/munmaps each on some > big file. Here are the results: > > Before: > # time ./pthread_mmap ./randfile > real 3m33.118s > user 0m3.698s > sys 3m16.624s > > After: > # time ./pthread_mmap ./randfile > real 2m19.920s > user 0m2.662s > sys 2m9.948s > > This series brings a number of small improvements along the way: fast > hypercall implementation and using it for event signaling, rep hypercalls > implementation, hyperv tracing subsystem (which only traces the newly added > remote TLB flush for now). > > Vitaly Kuznetsov (10): > x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set > x86/hyper-v: stash the max number of virtual/logical processor > x86/hyper-v: make hv_do_hypercall() inline > x86/hyper-v: fast hypercall implementation > hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT > x86/hyper-v: implement rep hypercalls > hyper-v: globalize vp_index > x86/hyper-v: use hypercall for remote TLB flush > x86/hyper-v: support extended CPU ranges for TLB flush hypercalls > tracing/hyper-v: trace hyperv_mmu_flush_tlb_others() > > MAINTAINERS | 1 + > arch/x86/Kbuild | 2 +- > arch/x86/hyperv/Makefile| 2 +- > arch/x86/hyperv/hv_init.c | 90 ++-- > arch/x86/hyperv/mmu.c | 268 > > arch/x86/include/asm/mshyperv.h | 148 +++- > arch/x86/include/asm/trace/hyperv.h | 38 + > arch/x86/include/uapi/asm/hyperv.h | 17 +++ > arch/x86/kernel/cpu/mshyperv.c | 13 +- > drivers/hv/channel_mgmt.c | 20 +-- > drivers/hv/connection.c | 7 +- > drivers/hv/hv.c | 9 -- > drivers/hv/hyperv_vmbus.h | 11 -- > drivers/hv/vmbus_drv.c | 17 --- > drivers/pci/host/pci-hyperv.c | 10 +- > include/linux/hyperv.h | 17 +-- > 16 files changed, 539 insertions(+), 131 deletions(-) > create mode 100644 arch/x86/hyperv/mmu.c > create mode 100644 arch/x86/include/asm/trace/hyperv.h > Looks good. Reviewed-by: Stephen Hemminger ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 0/6] netvsc: small cleanups
From: Stephen Hemminger Date: Thu, 8 Jun 2017 16:21:17 -0700 > These are all small optimizations found during development of later features. Applied with the spelling error pointed out by Sergei fixed. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
On Fri, 9 Jun 2017 15:27:36 +0200
Vitaly Kuznetsov wrote:
> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
> Tracing is done the same way we do xen_mmu_flush_tlb_others().
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> MAINTAINERS | 1 +
> arch/x86/hyperv/mmu.c | 7 +++
> arch/x86/include/asm/trace/hyperv.h | 38
> +
> 3 files changed, 46 insertions(+)
> create mode 100644 arch/x86/include/asm/trace/hyperv.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e3f44fd..001614b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6168,6 +6168,7 @@ M: Stephen Hemminger
> L: de...@linuxdriverproject.org
> S: Maintained
> F: arch/x86/include/asm/mshyperv.h
> +F: arch/x86/include/asm/trace/hyperv.h
> F: arch/x86/include/uapi/asm/hyperv.h
> F: arch/x86/kernel/cpu/mshyperv.c
> F: arch/x86/hyperv
> diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c
> index 0712111..cb35453 100644
> --- a/arch/x86/hyperv/mmu.c
> +++ b/arch/x86/hyperv/mmu.c
> @@ -8,6 +8,9 @@
> #include
> #include
>
> +#define CREATE_TRACE_POINTS
> +#include
> +
> /* HvFlushVirtualAddressSpace, HvFlushVirtualAddressList hypercalls */
> struct hv_flush_pcpu {
> u64 address_space;
> @@ -103,6 +106,8 @@ static void hyperv_flush_tlb_others(const struct cpumask
> *cpus,
> u64 status = U64_MAX;
> unsigned long flags;
>
> + trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
> +
> if (!pcpu_flush || !hv_hypercall_pg)
> goto do_native;
>
> @@ -172,6 +177,8 @@ static void hyperv_flush_tlb_others_ex(const struct
> cpumask *cpus,
> u64 status = U64_MAX;
> unsigned long flags;
>
> + trace_hyperv_mmu_flush_tlb_others(cpus, mm, start, end);
> +
> if (!pcpu_flush_ex || !hv_hypercall_pg)
> goto do_native;
>
> diff --git a/arch/x86/include/asm/trace/hyperv.h
> b/arch/x86/include/asm/trace/hyperv.h
> new file mode 100644
> index 000..e44ece1
> --- /dev/null
> +++ b/arch/x86/include/asm/trace/hyperv.h
> @@ -0,0 +1,38 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM hyperv
> +
> +#if !defined(_TRACE_HYPERV_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_HYPERV_H
> +
> +#include
> +
> +#if IS_ENABLED(CONFIG_HYPERV)
Hmm, this is new to me. I know you can use IS_ENABLED() inside C code,
but I've never seen it used for preprocessor directives. This usually
is just:
#ifdef CONFIG_HYPERV
Other than that, this looks fine to me.
-- Steve
> +
> +TRACE_EVENT(hyperv_mmu_flush_tlb_others,
> + TP_PROTO(const struct cpumask *cpus, struct mm_struct *mm,
> + unsigned long addr, unsigned long end),
> + TP_ARGS(cpus, mm, addr, end),
> + TP_STRUCT__entry(
> + __field(unsigned int, ncpus)
> + __field(struct mm_struct *, mm)
> + __field(unsigned long, addr)
> + __field(unsigned long, end)
> + ),
> + TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
> +__entry->mm = mm;
> +__entry->addr = addr,
> +__entry->end = end),
> + TP_printk("ncpus %d mm %p addr %lx, end %lx",
> + __entry->ncpus, __entry->mm, __entry->addr, __entry->end)
> + );
> +
> +#endif /* CONFIG_HYPERV */
> +
> +#undef TRACE_INCLUDE_PATH
> +#define TRACE_INCLUDE_PATH asm/trace/
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_FILE hyperv
> +#endif /* _TRACE_HYPERV_H */
> +
> +/* This part must be outside protection */
> +#include
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote: > On Fri, 9 Jun 2017 15:27:36 +0200 > Vitaly Kuznetsov wrote: >> +#if IS_ENABLED(CONFIG_HYPERV) > > Hmm, this is new to me. I know you can use IS_ENABLED() inside C code, > but I've never seen it used for preprocessor directives. This usually > is just: > > #ifdef CONFIG_HYPERV > > Other than that, this looks fine to me. That is the magic of IS_ENABLED(), IS_BUILTIN() macros. So, the code above is fine as is. -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
On Fri, 9 Jun 2017 21:23:52 +0300 Andy Shevchenko wrote: > On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote: > > On Fri, 9 Jun 2017 15:27:36 +0200 > > Vitaly Kuznetsov wrote: > > > >> +#if IS_ENABLED(CONFIG_HYPERV) > > > > Hmm, this is new to me. I know you can use IS_ENABLED() inside C code, > > but I've never seen it used for preprocessor directives. This usually > > is just: > > > > #ifdef CONFIG_HYPERV > > > > Other than that, this looks fine to me. > > That is the magic of IS_ENABLED(), IS_BUILTIN() macros. > So, the code above is fine as is. > I'm sure it works, but it just adds one more way of doing the same thing. I thought that was what perl was always criticized for, and why people usually prefer python. Don't get me wrong, I prefer oysters over snakes. But I just wanted to point out the lack of consistency here. -- Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
On Fri, Jun 9, 2017 at 9:32 PM, Steven Rostedt wrote: > On Fri, 9 Jun 2017 21:23:52 +0300 > Andy Shevchenko wrote: > I'm sure it works, but it just adds one more way of doing the same > thing. I thought that was what perl was always criticized for, and why > people usually prefer python. Don't get me wrong, I prefer oysters over > snakes. But I just wanted to point out the lack of consistency here. Fair enough. -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: ks7010: ks_hostif.c: Fixed alignment to match open parenthesis
Fixed alignment so that it matched open paranthesis .
Signed-off-by: srishti sharma
---
drivers/staging/ks7010/ks_hostif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index 697347b..e3c11be 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1659,8 +1659,8 @@ void hostif_phy_information_request(struct
ks_wlan_private *priv)
static
void hostif_power_mgmt_request(struct ks_wlan_private *priv,
- unsigned long mode, unsigned long wake_up,
- unsigned long receive_dtims)
+ unsigned long mode, unsigned long wake_up,
+ unsigned long receive_dtims)
{
struct hostif_power_mgmt_request_t *pp;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote: > I'm sure it works, but it just adds one more way of doing the same > thing. I thought that was what perl was always criticized for, and why > people usually prefer python. Don't get me wrong, I prefer oysters over > snakes. But I just wanted to point out the lack of consistency here. A major benefit is that #if IS_ENABLED(CONFIG_HYPERV) is shorter than #if defined(CONFIG_HYPERV) || defined(CONFIG_HYPERV_MODULE) and less prone to typos. Paul Bolle ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ks7010: ks_hostif.c: Fixed alignment to match open parenthesis
On Sat, Jun 10, 2017 at 12:25 AM, srishti sharma wrote:
> Fixed alignment so that it matched open paranthesis .
>
> Signed-off-by: srishti sharma
> ---
> drivers/staging/ks7010/ks_hostif.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/ks7010/ks_hostif.c
> b/drivers/staging/ks7010/ks_hostif.c
> index 697347b..e3c11be 100644
> --- a/drivers/staging/ks7010/ks_hostif.c
> +++ b/drivers/staging/ks7010/ks_hostif.c
> @@ -1659,8 +1659,8 @@ void hostif_phy_information_request(struct
> ks_wlan_private *priv)
>
> static
> void hostif_power_mgmt_request(struct ks_wlan_private *priv,
> - unsigned long mode, unsigned long wake_up,
> - unsigned long receive_dtims)
> + unsigned long mode, unsigned long wake_up,
> + unsigned long receive_dtims)
> {
> struct hostif_power_mgmt_request_t *pp;
>
> --
> 2.7.4
Okay , this doesn't look right , please ignore ! Sorry
Thanks
Srishti
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 10/10] tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()
On Fri, 09 Jun 2017 20:53:53 +0200 Paul Bolle wrote: > On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote: > > I'm sure it works, but it just adds one more way of doing the same > > thing. I thought that was what perl was always criticized for, and why > > people usually prefer python. Don't get me wrong, I prefer oysters over > > snakes. But I just wanted to point out the lack of consistency here. > > A major benefit is that > #if IS_ENABLED(CONFIG_HYPERV) > > is shorter than > #if defined(CONFIG_HYPERV) || defined(CONFIG_HYPERV_MODULE) > > and less prone to typos. > I don't believe the module version is needed here. Otherwise I would question the #if altogether. Which now I'm looking at it, why is it needed? What includes this header file that wouldn't have that set anyway? The only place it is included is in: arch/x86/hyperv/mmu.c Is that compiled without CONFIG_HYPERV? -- Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: vc04_services: bcm2835-audio: bcm2835-ctl.c: Fixed alignment to match open parenthesis.
Fixed alignment so that it matched open parenthesis.
Signed-off-by: srishti sharma
---
drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index f484bb0..2148ed0 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -105,7 +105,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol
*kcontrol,
}
static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
{
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int changed = 0;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote: > > > On 06/08/2017 01:25 PM, Tim Harvey wrote: > > > > > >Steve, > > > >You need to remove the fim node now that you've moved this to V4L2 controls. > > > > Yep, I caught this just after sending the v8 patchset. I'll send > a v9 of this patch. This needs ack from devicetree people, then it can be merged. Can you be a bit more forceful getting the ack? I don't think it makes sense to resubmit v9 before that. This is not a rocket science. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
On 06/09/2017 02:38 PM, Pavel Machek wrote: On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote: On 06/08/2017 01:25 PM, Tim Harvey wrote: Steve, You need to remove the fim node now that you've moved this to V4L2 controls. Yep, I caught this just after sending the v8 patchset. I'll send a v9 of this patch. This needs ack from devicetree people, then it can be merged. Can you be a bit more forceful getting the ack? OK, I need an Ack please, he said, in a forceful way. :) In fact Ack's are needed for all the changes to dts sources, patches 4-14. I don't think it makes sense to resubmit v9 before that. This is not a rocket science. I guess that makes sense, I'll wait for Ack's from all these patches before submitting the entire patchset as v9. Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 19/34] media: Add i.MX media core driver
On 06/09/2017 06:15 AM, Philipp Zabel wrote:
On Wed, 2017-06-07 at 11:33 -0700, Steve Longerbeam wrote:
Add the core media driver for i.MX SOC.
Signed-off-by: Steve Longerbeam
Switch from the v4l2_of_ APIs to the v4l2_fwnode_ APIs.
Signed-off-by: Philipp Zabel
Add the bayer formats to imx-media's list of supported pixel and bus
formats.
Signed-off-by: Russell King
---
[...]
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
new file mode 100644
index 000..da694f6
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -0,0 +1,666 @@
[...]
+/*
+ * adds given video device to given imx-media source pad vdev list.
+ * Continues upstream from the pad entity's sink pads.
+ */
+static int imx_media_add_vdev_to_pad(struct imx_media_dev *imxmd,
+struct imx_media_video_dev *vdev,
+struct media_pad *srcpad)
+{
+ struct media_entity *entity = srcpad->entity;
+ struct imx_media_subdev *imxsd;
+ struct imx_media_pad *imxpad;
+ struct media_link *link;
+ struct v4l2_subdev *sd;
+ int i, vdev_idx, ret;
+
+ if (!is_media_entity_v4l2_subdev(entity))
+ return -EINVAL;
Could we make this return 0, to just skip non-v4l2_subdev entities?
Currently, imx_media_probe_complete silently fails with this -EINVAL if
there is a tvp5150 connected due to the separate media entities that the
tvp5150 driver creates for the input connectors (Composite0, for
example).
Right, I've made that change.
Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 00/34] i.MX Media Driver
On 06/07/2017 12:02 PM, Hans Verkuil wrote: We're still waiting for an Ack for patch 02/34, right? Hi Hans, Rub has provided an Ack for patch 2. Other than that everything is ready AFAICT. But as Pavel pointed out, in fact we are missing many Acks still, for all of the dts source changes (patches 4-14), as well as really everything else (imx-media staging driver patches). Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 00/34] i.MX Media Driver
On 06/09/2017 04:16 PM, Steve Longerbeam wrote: On 06/07/2017 12:02 PM, Hans Verkuil wrote: We're still waiting for an Ack for patch 02/34, right? Hi Hans, Rub damn, I really need to proof-read before hitting send. "Rob" (sorry Rob!). Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
Hi! > >>>Steve, > >>> > >>>You need to remove the fim node now that you've moved this to V4L2 > >>>controls. > >>> > >> > >>Yep, I caught this just after sending the v8 patchset. I'll send > >>a v9 of this patch. > > > >This needs ack from devicetree people, then it can be merged. Can you > >be a bit more forceful getting the ack? > > OK, I need an Ack please, he said, in a forceful way. :) I'd tune the force up a tiny bit more. This is not FreeBSD ;-). You can read some emails from Linus for inspiration. Or drink few beers and look at Al Viro's emails. > In fact Ack's are needed for all the changes to dts sources, > patches 4-14. Actually, are they? Those should not need acks from device tree people, just acks from ARM people, and those are easier to get... in fact they should not need any acks, you should just send them to arm people and get them merged. 1-4 is just a documentation, and you have acks there. (Except 2?) That's ready to be merged, probably via the media tree? Just make it clear you want it merged. 15,16 should be ready to. Media tree, too, I guess. drivers/staging is greg. Advantage is these do _not_ need to go after the dts changes. It is a driver. Actually I'd normally add dts support after the driver. So you can push it now. > >I don't think it makes sense to resubmit v9 before that. This is not a > >rocket science. > > I guess that makes sense, I'll wait for Ack's from all these patches > before submitting the entire patchset as v9. You may want to split the series, according to mainainters, or just ask the maintainers to merge the relevant parts. I believe most of it can be pushed now. Good luck, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 00/34] i.MX Media Driver
On 10/06/17 01:16, Steve Longerbeam wrote: > > > On 06/07/2017 12:02 PM, Hans Verkuil wrote: >> We're still waiting for an Ack for patch 02/34, right? >> > > Hi Hans, Rub has provided an Ack for patch 2. > >> Other than that everything is ready AFAICT. >> > > But as Pavel pointed out, in fact we are missing many > Acks still, for all of the dts source changes (patches > 4-14), as well as really everything else (imx-media staging > driver patches). No Acks needed for the staging part. It's staging, so not held to the same standards as non-staging parts. That doesn't mean Acks aren't welcome, of course. You don't need Greg's Ack for staging/media either, patches there go in via us (generally at least) and we handle those, not Greg. Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
On 06/09/2017 04:23 PM, Pavel Machek wrote: Hi! Steve, You need to remove the fim node now that you've moved this to V4L2 controls. Yep, I caught this just after sending the v8 patchset. I'll send a v9 of this patch. This needs ack from devicetree people, then it can be merged. Can you be a bit more forceful getting the ack? OK, I need an Ack please, he said, in a forceful way. :) I'd tune the force up a tiny bit more. This is not FreeBSD ;-). You can read some emails from Linus for inspiration. Or drink few beers and look at Al Viro's emails. In fact Ack's are needed for all the changes to dts sources, patches 4-14. Actually, are they? Those should not need acks from device tree people, just acks from ARM people, and those are easier to get... in fact they should not need any acks, you should just send them to arm people and get them merged. Hans said he prefers to have the dts patches as part of the whole set rather than submitted separately. But I did add --to's for the ARM people for 4-14. 1-4 is just a documentation, and you have acks there. (Except 2?) That's ready to be merged, probably via the media tree? Just make it clear you want it merged. Yes, 1-3 now have Acks (binding docs). 15,16 should be ready to. Media tree, too, I guess. Yes, those have Acks (video-mux entity functions and subdev driver). drivers/staging is greg. Advantage is these do _not_ need to go after the dts changes. It is a driver. Actually I'd normally add dts support after the driver. So you can push it now. Right, Hans agrees, except that for staging drivers we don't really need an Ack from Greg. I don't think it makes sense to resubmit v9 before that. This is not a rocket science. I guess that makes sense, I'll wait for Ack's from all these patches before submitting the entire patchset as v9. You may want to split the series, according to mainainters, or just ask the maintainers to merge the relevant parts. I believe most of it can be pushed now. Good luck, Thanks! Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Drivers: rtl8723bs - remove asm includes
Fixed checkpatch warnings "Use #include instead of " Found using checkpatch Signed-off-by: Derek Robson --- drivers/staging/rtl8723bs/include/osdep_service_linux.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8723bs/include/osdep_service_linux.h b/drivers/staging/rtl8723bs/include/osdep_service_linux.h index 486e8184b0b2..0c9b4f622fee 100644 --- a/drivers/staging/rtl8723bs/include/osdep_service_linux.h +++ b/drivers/staging/rtl8723bs/include/osdep_service_linux.h @@ -26,10 +26,10 @@ /* include */ #include #include - #include + #include #include - #include - #include + #include + #include #include #include #include -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: llite: Make structure describing various file operations 'const'
Hi Roman,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Roman-Storozhenko/staging-lustre-llite-Make-structure-describing-various-file-operations-const/20170610-121428
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
>> drivers/staging/lustre/lustre/llite/file.c:3117:8: error: expected '{'
>> before 'const'
struct const file_operations ll_file_operations = {
^
drivers/staging/lustre/lustre/llite/file.c:3130:8: error: expected '{'
before 'const'
struct const file_operations ll_file_operations_flock = {
^
drivers/staging/lustre/lustre/llite/file.c:3146:8: error: expected '{'
before 'const'
struct const file_operations ll_file_operations_noflock = {
^
drivers/staging/lustre/lustre/llite/file.c:2706:1: warning:
'll_file_noflock' defined but not used [-Wunused-function]
ll_file_noflock(struct file *file, int cmd, struct file_lock *file_lock)
^~~
drivers/staging/lustre/lustre/llite/file.c:2408:1: warning: 'll_file_flock'
defined but not used [-Wunused-function]
ll_file_flock(struct file *file, int cmd, struct file_lock *file_lock)
^
drivers/staging/lustre/lustre/llite/file.c:2281:12: warning: 'll_flush'
defined but not used [-Wunused-function]
static int ll_flush(struct file *file, fl_owner_t id)
^~~~
drivers/staging/lustre/lustre/llite/file.c:2259:15: warning: 'll_file_seek'
defined but not used [-Wunused-function]
static loff_t ll_file_seek(struct file *file, loff_t offset, int origin)
^~~~
drivers/staging/lustre/lustre/llite/file.c:1925:1: warning: 'll_file_ioctl'
defined but not used [-Wunused-function]
ll_file_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
^
drivers/staging/lustre/lustre/llite/file.c:1177:16: warning:
'll_file_write_iter' defined but not used [-Wunused-function]
static ssize_t ll_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
^~
drivers/staging/lustre/lustre/llite/file.c:1153:16: warning:
'll_file_read_iter' defined but not used [-Wunused-function]
static ssize_t ll_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
^
vim +3117 drivers/staging/lustre/lustre/llite/file.c
3111 }
3112
3113 return rc;
3114 }
3115
3116 /* -o localflock - only provides locally consistent flock locks */
> 3117 struct const file_operations ll_file_operations = {
3118 .read_iter = ll_file_read_iter,
3119 .write_iter = ll_file_write_iter,
3120 .unlocked_ioctl = ll_file_ioctl,
---
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:driver-core-next 27/39] arch/arm/mach-rpc/ecard.c:792:23: error: 'resource_show_show' undeclared here (not in a function)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
driver-core-next
head: 4fe99816a1ab0323c39949bd0ee99a97b7e5875f
commit: 71d1e5d71cec76e927a92354a7eb9d476e7054ad [27/39] arm: ecard: use
dev_groups and not dev_attrs for bus_type
config: arm-rpc_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 71d1e5d71cec76e927a92354a7eb9d476e7054ad
# save the attached .config to linux build tree
make.cross ARCH=arm
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kobject.h:21:0,
from include/linux/module.h:17,
from arch/arm/mach-rpc/ecard.c:30:
>> arch/arm/mach-rpc/ecard.c:792:23: error: 'resource_show_show' undeclared
>> here (not in a function)
static DEVICE_ATTR_RO(resource_show)
^
include/linux/sysfs.h:116:10: note: in definition of macro '__ATTR_RO'
.show = _name##_show, \
^
>> arch/arm/mach-rpc/ecard.c:792:8: note: in expansion of macro 'DEVICE_ATTR_RO'
static DEVICE_ATTR_RO(resource_show)
^~
>> arch/arm/mach-rpc/ecard.c:794:1: error: expected ',' or ';' before 'static'
static ssize_t vendor_show(struct device *dev, struct device_attribute
*attr, char *buf)
^~
In file included from include/linux/kobject.h:21:0,
from include/linux/module.h:17,
from arch/arm/mach-rpc/ecard.c:30:
>> arch/arm/mach-rpc/ecard.c:799:23: error: 'vendor_show' undeclared here (not
>> in a function)
static DEVICE_ATTR_RO(vendor);
^
include/linux/sysfs.h:116:10: note: in definition of macro '__ATTR_RO'
.show = _name##_show, \
^
arch/arm/mach-rpc/ecard.c:799:8: note: in expansion of macro 'DEVICE_ATTR_RO'
static DEVICE_ATTR_RO(vendor);
^~
>> arch/arm/mach-rpc/ecard.c:819:3: error: 'dev_attr_resource' undeclared here
>> (not in a function)
&dev_attr_resource.attr,
^
In file included from arch/arm/mach-rpc/ecard.c:42:0:
include/linux/device.h:584:26: warning: 'dev_attr_resource_show' defined but
not used [-Wunused-variable]
struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
^
>> arch/arm/mach-rpc/ecard.c:792:8: note: in expansion of macro 'DEVICE_ATTR_RO'
static DEVICE_ATTR_RO(resource_show)
^~
arch/arm/mach-rpc/ecard.c:778:16: warning: 'resource_show' defined but not
used [-Wunused-function]
static ssize_t resource_show(struct device *dev, struct device_attribute
*attr, char *buf)
^
vim +/resource_show_show +792 arch/arm/mach-rpc/ecard.c
786 ec->resource[i].start,
787 ec->resource[i].end,
788 ec->resource[i].flags);
789
790 return str - buf;
791 }
> 792 static DEVICE_ATTR_RO(resource_show)
793
> 794 static ssize_t vendor_show(struct device *dev, struct device_attribute
> *attr, char *buf)
795 {
796 struct expansion_card *ec = ECARD_DEV(dev);
797 return sprintf(buf, "%u\n", ec->cid.manufacturer);
798 }
> 799 static DEVICE_ATTR_RO(vendor);
800
801 static ssize_t device_show(struct device *dev, struct device_attribute
*attr, char *buf)
802 {
803 struct expansion_card *ec = ECARD_DEV(dev);
804 return sprintf(buf, "%u\n", ec->cid.product);
805 }
806 static DEVICE_ATTR_RO(device);
807
808 static ssize_t type_show(struct device *dev, struct device_attribute
*attr, char *buf)
809 {
810 struct expansion_card *ec = ECARD_DEV(dev);
811 return sprintf(buf, "%s\n", ec->easi ? "EASI" : "IOC");
812 }
813 static DEVICE_ATTR_RO(type);
814
815 static struct attribute *ecard_dev_attrs[] = {
816 &dev_attr_device.attr,
817 &dev_attr_dma.attr,
818 &dev_attr_irq.attr,
> 819 &dev_attr_resource.attr,
820 &dev_attr_type.attr,
821 &dev_attr_vendor.attr,
822 NULL,
---
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
