Re: [v3,1/4] input: add an EV_REL event for high-res vertical wheel
Em Fri, 7 Apr 2017 17:10:27 +0200 Benjamin Tissoires escreveu: > On Apr 07 2017 or thereabouts, Mauro Carvalho Chehab wrote: > > Em Fri, 7 Apr 2017 14:17:51 +0200 > > Benjamin Tissoires escreveu: > > > > > Hi Mauro, > > > > > > On Apr 07 2017 or thereabouts, Mauro Carvalho Chehab wrote: > > > > As some devices can produce either low-res or high-res > > > > vertical wheel EV_REL events, add a new event to allow > > > > userspace to distinguish between them. > > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > --- > > > > Documentation/input/event-codes.rst| 16 +--- > > > > include/uapi/linux/input-event-codes.h | 1 + > > > > 2 files changed, 14 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/Documentation/input/event-codes.rst > > > > b/Documentation/input/event-codes.rst > > > > index 92db50954169..0c8591d39bc6 100644 > > > > --- a/Documentation/input/event-codes.rst > > > > +++ b/Documentation/input/event-codes.rst > > > > @@ -185,10 +185,20 @@ instead of EV_REL codes. > > > > > > > > A few EV_REL codes have special meanings: > > > > > > > > -* REL_WHEEL, REL_HWHEEL: > > > > +* REL_WHEEL: > > > > > > > > - - These codes are used for vertical and horizontal scroll wheels, > > > > -respectively. > > > > + - These codes are used for vertical scroll wheels. > > > > + > > > > + - REL_WHEEL is for normal wheel operational mode, e. g. > > > > low-resolution > > > > +(line-based) scroll. > > > > + > > > > + - REL_HIRES_WHEEL should be used when the wheel has two resolutions > > > > and it > > > > +is in high-resolution mode, e. g. the same angular movement that > > > > would > > > > +produce a single REL_WHEEL will produce multiple REL_HIRES_WHEEL > > > > events. > > > > + > > > > +* REL_HWHEEL: > > > > + > > > > + - This code is used for horizontal scroll wheels. > > > > > > > > EV_ABS > > > > -- > > > > diff --git a/include/uapi/linux/input-event-codes.h > > > > b/include/uapi/linux/input-event-codes.h > > > > index 3af60ee69053..23b2d377af59 100644 > > > > --- a/include/uapi/linux/input-event-codes.h > > > > +++ b/include/uapi/linux/input-event-codes.h > > > > @@ -703,6 +703,7 @@ > > > > #define REL_DIAL 0x07 > > > > #define REL_WHEEL 0x08 > > > > #define REL_MISC 0x09 > > > > +#define REL_HIRES_WHEEL0x0a > > > > > > There is one issue here. The HID input layer has a tendency to map > > > usages to REL_MISC +1, +2, +3, etc... When it doesn't know how to map an > > > usage, the core layer maps it to the next one. > > > > > > I am not aware of devices exposing such REL axes, but I wouldn't be > > > surprised if the issue will not raise at some point. > > > > > > We already had an issue with ABS events where ABS_MISC are conflicting > > > with ABS_MT_SLOTS. Luckily, we have a little empty space between > > > ABS_MISC and ABS_MT_SLOT, which allows userspace to detect such issues. > > > > > > Could you give the define a bigger number (and maybe reserve a couple of > > > REL_MISC-n) to make sure that we do not end up with joysticks exporting > > > REL_HIRES_WHEEL? > > > > Sure. How many REL_MISC-n should be reserved? > > Not sure. As I mentioned, I haven' t seen such device myself, but maybe > we should reserve the rest of the 0x0n range for those (0x0a-0x0f). This > would force to bump REL_MAX, but I don't think this is an issue besides > recompiling libevdev and others. Ok, I'll do that on a separate patch. Btw, you requested to rebase patches on the top of HID tree. Well, if I rebase on the top of HID for_next branch, patches 1 and 2 will have (trivial) conflicts with input-next, due to the documentation patches that got merged there. I might rebase just patches 3 and 4, but, in this case, the HID branch won't compile. So, I guess either input should pull from HID or vice-versa, in order to avoid such conflicts. > > > > > > I'll try the rest of the series on the MX Master today. > > > > It would be great if you could test it! > > I found some issues, I'll report in the other patches. Ok. > > Cheers, > Benjamin > > > > > Regards, > > Mauro Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] docs-rst: add input docs at main index and use kernel-figure
The input subsystem documentation got converted into ReST. Add it to the main documentation index and use kernel-figure for the two svg images there. Signed-off-by: Mauro Carvalho Chehab --- Jon/Dmitry, This patch contains the final bits of the input documentation conversion. The linux-input tree has already the ReST conversion patches, but it doesn't have the Documentation/sphinx/load_config.py script with implements the kernel-figure directive, as it got merged via docs tree. So, either one of you should merge from the other tree or this patch should be sent in separate upstream after both trees gets merged. What do you prefer? Thanks! Mauro Documentation/index.rst| 1 + Documentation/input/ff.rst | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/index.rst b/Documentation/index.rst index 61306a22888d..bc67dbf76eb0 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -67,6 +67,7 @@ needed). driver-api/index core-api/index media/index + input/index gpu/index security/index sound/index diff --git a/Documentation/input/ff.rst b/Documentation/input/ff.rst index c30f185216a0..0ea123c64dd2 100644 --- a/Documentation/input/ff.rst +++ b/Documentation/input/ff.rst @@ -129,11 +129,11 @@ Effects are file descriptor specific. See for a description of the ff_effect struct. You should also find help in a few sketches, contained in files shape.svg and interactive.svg: -.. figure:: shape.svg +.. kernel-figure:: shape.svg Shape -.. figure:: interactive.svg +.. kernel-figure:: interactive.svg Interactive -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Mon, Apr 10, 2017 at 11:47:40PM +0400, Yury Norov wrote: > According to latest plans figured out on Linaro Connect, ILP32 should > be taken in 4.12 merge window. Sorry, I wasn't present at Linaro Connect, so definitely not involved in such decision. BTW, it would be nice to have Arnd's ack on patch 2 (32-bit ABI: introduce ARCH_32BIT_OFF_T config option). > The window will be opened in less than a month, so I'd like to remind > it to you, and ask if you have any questions/requests related to > ILP32. Is it still realistic idea to take patches in 4.12? 4.12 is not realistic and I wouldn't commit to a specific kernel version. Given the intrusiveness, such patches should sit in -next for at least 3-4 weeks (i.e. merged in the arch tree around -rc3). Anyway, I don't think the plan has changed since last time I stated it: https://lkml.org/lkml/2016/12/5/333 I haven't got the chance to test these patches yet, run benchmarks (step 4). Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). Is there an up to date pre-built toolchain and a filesystem for ILP32? On the glibc testing side, have the regressions been identified/fixed? -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] kvm: better MWAIT emulation for guests
From: "Michael S. Tsirkin" Guests that are heavy on futexes end up IPI'ing each other a lot. That can lead to significant slowdowns and latency increase for those guests when running within KVM. If only a single guest is needed on a host, we have a lot of spare host CPU time we can throw at the problem. Modern CPUs implement a feature called "MWAIT" which allows guests to wake up sleeping remote CPUs without an IPI - thus without an exit - at the expense of never going out of guest context. The decision whether this is something sensible to use should be up to the VM admin, so to user space. We can however allow MWAIT execution on systems that support it properly hardware wise. This patch adds a CAP to user space and a KVM cpuid leaf to indicate availability of native MWAIT execution. With that enabled, the worst a guest can do is waste as many cycles as a "jmp ." would do, so it's not a privilege problem. We consciously do *not* expose the feature in our CPUID bitmap, as most people will want to benefit from sleeping vCPUs to allow for over commit. Reported-by: "Gabriel L. Somlo" Signed-off-by: Michael S. Tsirkin [agraf: fix amd, change commit message] Signed-off-by: Alexander Graf --- v5 -> v6: - Fix AMD check, so that we're consistent between svm and vmx - Clarify commit message --- Documentation/virtual/kvm/api.txt| 9 + Documentation/virtual/kvm/cpuid.txt | 6 ++ arch/x86/include/uapi/asm/kvm_para.h | 1 + arch/x86/kvm/cpuid.c | 3 +++ arch/x86/kvm/svm.c | 7 +-- arch/x86/kvm/vmx.c | 6 -- arch/x86/kvm/x86.c | 3 +++ arch/x86/kvm/x86.h | 36 include/uapi/linux/kvm.h | 1 + 9 files changed, 68 insertions(+), 4 deletions(-) diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 1a18484..dacc3d7 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -4094,3 +4094,12 @@ reserved. 2: MIPS64 or microMIPS64 with access to all address segments. Both registers and addresses are 64-bits wide. It will be possible to run 64-bit or 32-bit guest code. + +8.8 KVM_CAP_X86_GUEST_MWAIT + +Architectures: x86 + +This capability indicates that guest using memory monotoring instructions +(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit. As such time +spent while virtual CPU is halted in this way will then be accounted for as +guest running time on the host (as opposed to e.g. HLT). diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 3c65feb..04c201c 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit || || before enabling paravirtualized || || spinlock support. -- +KVM_FEATURE_MWAIT || 8 || guest can use monitor/mwait + || || to halt the VCPU without exits, + || || time spent while halted in this + || || way is accounted for on host as + || || VCPU run time. +-- KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side || || per-cpu warps are expected in || || kvmclock. diff --git a/arch/x86/include/uapi/asm/kvm_para.h b/arch/x86/include/uapi/asm/kvm_para.h index cff0bb6..9cc77a7 100644 --- a/arch/x86/include/uapi/asm/kvm_para.h +++ b/arch/x86/include/uapi/asm/kvm_para.h @@ -24,6 +24,7 @@ #define KVM_FEATURE_STEAL_TIME 5 #define KVM_FEATURE_PV_EOI 6 #define KVM_FEATURE_PV_UNHALT 7 +#define KVM_FEATURE_MWAIT 8 /* The last 8 bits are used to indicate how to interpret the flags field * in pvclock structure. If no bits are set, all flags are ignored. diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index efde6cc..5638102 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function, if (sched_info_on()) entry->eax |= (1 << KVM_FEATURE_STEAL_TIME); + if (kvm_mwait_in_guest()) + entry->eax |= (1 << KVM_FEATURE_MWAIT); + entry->ebx = 0; entry->ecx = 0; entry->edx = 0; diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 1b203ab..c41f03e 100644 --- a/arch/x86/kvm/svm.c +++ b/ar
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Apr 11 2017, Catalin Marinas wrote: > Is there an up to date pre-built toolchain and a filesystem for ILP32? https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32 should have everything you need. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] kvm: better MWAIT emulation for guests
On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote: > From: "Michael S. Tsirkin" > > Guests that are heavy on futexes end up IPI'ing each other a lot. That > can lead to significant slowdowns and latency increase for those guests > when running within KVM. > > If only a single guest is needed on a host, we have a lot of spare host > CPU time we can throw at the problem. Modern CPUs implement a feature > called "MWAIT" which allows guests to wake up sleeping remote CPUs without > an IPI - thus without an exit - at the expense of never going out of guest > context. > > The decision whether this is something sensible to use should be up to the > VM admin, so to user space. We can however allow MWAIT execution on systems > that support it properly hardware wise. > > This patch adds a CAP to user space and a KVM cpuid leaf to indicate > availability of native MWAIT execution. With that enabled, the worst a > guest can do is waste as many cycles as a "jmp ." would do, so it's not > a privilege problem. Did you mean "hlt" rather than "jmp" ? > We consciously do *not* expose the feature in our CPUID bitmap, as most > people will want to benefit from sleeping vCPUs to allow for over commit. > > Reported-by: "Gabriel L. Somlo" That's maybe a bit inacurate, I didn't actually report anything *this* patch is trying to address (that was rather commit 87c00572ba05aa8c9d). Maybe Acked-by: Gabriel Somlo would be a more accurate statement instead? Thanks much, --Gabriel > Signed-off-by: Michael S. Tsirkin > [agraf: fix amd, change commit message] > Signed-off-by: Alexander Graf > > --- > > v5 -> v6: > > - Fix AMD check, so that we're consistent between svm and vmx > - Clarify commit message > --- > Documentation/virtual/kvm/api.txt| 9 + > Documentation/virtual/kvm/cpuid.txt | 6 ++ > arch/x86/include/uapi/asm/kvm_para.h | 1 + > arch/x86/kvm/cpuid.c | 3 +++ > arch/x86/kvm/svm.c | 7 +-- > arch/x86/kvm/vmx.c | 6 -- > arch/x86/kvm/x86.c | 3 +++ > arch/x86/kvm/x86.h | 36 > > include/uapi/linux/kvm.h | 1 + > 9 files changed, 68 insertions(+), 4 deletions(-) > > diff --git a/Documentation/virtual/kvm/api.txt > b/Documentation/virtual/kvm/api.txt > index 1a18484..dacc3d7 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -4094,3 +4094,12 @@ reserved. > 2: MIPS64 or microMIPS64 with access to all address segments. > Both registers and addresses are 64-bits wide. > It will be possible to run 64-bit or 32-bit guest code. > + > +8.8 KVM_CAP_X86_GUEST_MWAIT > + > +Architectures: x86 > + > +This capability indicates that guest using memory monotoring instructions > +(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit. As such > time > +spent while virtual CPU is halted in this way will then be accounted for as > +guest running time on the host (as opposed to e.g. HLT). > diff --git a/Documentation/virtual/kvm/cpuid.txt > b/Documentation/virtual/kvm/cpuid.txt > index 3c65feb..04c201c 100644 > --- a/Documentation/virtual/kvm/cpuid.txt > +++ b/Documentation/virtual/kvm/cpuid.txt > @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT || 7 || guest > checks this feature bit > || || before enabling > paravirtualized > || || spinlock support. > > -- > +KVM_FEATURE_MWAIT || 8 || guest can use monitor/mwait > + || || to halt the VCPU without > exits, > + || || time spent while halted in > this > + || || way is accounted for on host > as > + || || VCPU run time. > +-- > KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no > guest-side > || || per-cpu warps are expected in > || || kvmclock. > diff --git a/arch/x86/include/uapi/asm/kvm_para.h > b/arch/x86/include/uapi/asm/kvm_para.h > index cff0bb6..9cc77a7 100644 > --- a/arch/x86/include/uapi/asm/kvm_para.h > +++ b/arch/x86/include/uapi/asm/kvm_para.h > @@ -24,6 +24,7 @@ > #define KVM_FEATURE_STEAL_TIME 5 > #define KVM_FEATURE_PV_EOI 6 > #define KVM_FEATURE_PV_UNHALT7 > +#define KVM_FEATURE_MWAIT8 > > /* The last 8 bits are used to indicate how to interpret the flags field > * in pvclock structure. If no bits are set, all flags are ignored. > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index efde6cc..5638102 100644 > -
Re: [PATCH v6] kvm: better MWAIT emulation for guests
On 04/11/2017 02:41 PM, Gabriel L. Somlo wrote: On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote: From: "Michael S. Tsirkin" Guests that are heavy on futexes end up IPI'ing each other a lot. That can lead to significant slowdowns and latency increase for those guests when running within KVM. If only a single guest is needed on a host, we have a lot of spare host CPU time we can throw at the problem. Modern CPUs implement a feature called "MWAIT" which allows guests to wake up sleeping remote CPUs without an IPI - thus without an exit - at the expense of never going out of guest context. The decision whether this is something sensible to use should be up to the VM admin, so to user space. We can however allow MWAIT execution on systems that support it properly hardware wise. This patch adds a CAP to user space and a KVM cpuid leaf to indicate availability of native MWAIT execution. With that enabled, the worst a guest can do is waste as many cycles as a "jmp ." would do, so it's not a privilege problem. Did you mean "hlt" rather than "jmp" ? No, hlt wouldn't waste cycles, "jmp ." does. The point I'm trying to make here is that by removing the MWAIT trap we don't give the guest more CPU time than we would've granted it before. We consciously do *not* expose the feature in our CPUID bitmap, as most people will want to benefit from sleeping vCPUs to allow for over commit. Reported-by: "Gabriel L. Somlo" That's maybe a bit inacurate, I didn't actually report anything *this* patch is trying to address (that was rather commit 87c00572ba05aa8c9d). Maybe Acked-by: Gabriel Somlo would be a more accurate statement instead? Works for me :). I'm sure whoever applies this can swizzle the tag? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] kvm: better MWAIT emulation for guests
On Tue, Apr 11, 2017 at 08:41:11AM -0400, Gabriel L. Somlo wrote: > On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote: > > From: "Michael S. Tsirkin" > > > > Guests that are heavy on futexes end up IPI'ing each other a lot. That > > can lead to significant slowdowns and latency increase for those guests > > when running within KVM. > > > > If only a single guest is needed on a host, we have a lot of spare host > > CPU time we can throw at the problem. Modern CPUs implement a feature > > called "MWAIT" which allows guests to wake up sleeping remote CPUs without > > an IPI - thus without an exit - at the expense of never going out of guest > > context. > > > > The decision whether this is something sensible to use should be up to the > > VM admin, so to user space. We can however allow MWAIT execution on systems > > that support it properly hardware wise. > > > > This patch adds a CAP to user space and a KVM cpuid leaf to indicate > > availability of native MWAIT execution. With that enabled, the worst a > > guest can do is waste as many cycles as a "jmp ." would do, so it's not > > a privilege problem. > > Did you mean "hlt" rather than "jmp" ? Or, rather, "nop" ? (apologies, still waiting for the coffee to cool down to a drinkable temperature... :) > > We consciously do *not* expose the feature in our CPUID bitmap, as most > > people will want to benefit from sleeping vCPUs to allow for over commit. > > > > Reported-by: "Gabriel L. Somlo" > > That's maybe a bit inacurate, I didn't actually report anything *this* > patch is trying to address (that was rather commit 87c00572ba05aa8c9d). > > Maybe > > Acked-by: Gabriel Somlo > > would be a more accurate statement instead? > > Thanks much, > --Gabriel > > > Signed-off-by: Michael S. Tsirkin > > [agraf: fix amd, change commit message] > > Signed-off-by: Alexander Graf > > > > --- > > > > v5 -> v6: > > > > - Fix AMD check, so that we're consistent between svm and vmx > > - Clarify commit message > > --- > > Documentation/virtual/kvm/api.txt| 9 + > > Documentation/virtual/kvm/cpuid.txt | 6 ++ > > arch/x86/include/uapi/asm/kvm_para.h | 1 + > > arch/x86/kvm/cpuid.c | 3 +++ > > arch/x86/kvm/svm.c | 7 +-- > > arch/x86/kvm/vmx.c | 6 -- > > arch/x86/kvm/x86.c | 3 +++ > > arch/x86/kvm/x86.h | 36 > > > > include/uapi/linux/kvm.h | 1 + > > 9 files changed, 68 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/virtual/kvm/api.txt > > b/Documentation/virtual/kvm/api.txt > > index 1a18484..dacc3d7 100644 > > --- a/Documentation/virtual/kvm/api.txt > > +++ b/Documentation/virtual/kvm/api.txt > > @@ -4094,3 +4094,12 @@ reserved. > > 2: MIPS64 or microMIPS64 with access to all address segments. > > Both registers and addresses are 64-bits wide. > > It will be possible to run 64-bit or 32-bit guest code. > > + > > +8.8 KVM_CAP_X86_GUEST_MWAIT > > + > > +Architectures: x86 > > + > > +This capability indicates that guest using memory monotoring instructions > > +(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit. As such > > time > > +spent while virtual CPU is halted in this way will then be accounted for as > > +guest running time on the host (as opposed to e.g. HLT). > > diff --git a/Documentation/virtual/kvm/cpuid.txt > > b/Documentation/virtual/kvm/cpuid.txt > > index 3c65feb..04c201c 100644 > > --- a/Documentation/virtual/kvm/cpuid.txt > > +++ b/Documentation/virtual/kvm/cpuid.txt > > @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT || 7 || guest > > checks this feature bit > > || || before enabling > > paravirtualized > > || || spinlock support. > > > > -- > > +KVM_FEATURE_MWAIT || 8 || guest can use monitor/mwait > > + || || to halt the VCPU without > > exits, > > + || || time spent while halted in > > this > > + || || way is accounted for on > > host as > > + || || VCPU run time. > > +-- > > KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no > > guest-side > > || || per-cpu warps are expected > > in > > || || kvmclock. > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h > > b/arch/x86/include/uapi/asm/kvm_para.h > > index cff0bb6..9cc77a7 100644 > > --- a/arch/x86/include/uapi/asm/kvm_para.h > > +++ b/arch/x86/include/uapi/asm/kvm_para.h > > @@ -24,6 +24,7 @@ > > #define KVM_FEATUR
[PATCH v4 3/5] input: add a EV_SW event for ratchet switch
Some mice have a switch on their wheel, allowing to switch
between ratchet and free wheel mode. Add support for it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/input/event-codes.txt| 12
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/input/event-codes.txt
b/Documentation/input/event-codes.txt
index 50352ab5f6d4..5dbd45db9bf6 100644
--- a/Documentation/input/event-codes.txt
+++ b/Documentation/input/event-codes.txt
@@ -206,6 +206,18 @@ Upon resume, if the switch state is the same as before
suspend, then the input
subsystem will filter out the duplicate switch state reports. The driver does
not need to keep the state of the switch at any time.
+A few EV_SW codes have special meanings:
+
+* SW_RATCHET:
+
+ - Some mice have a special switch for their wheel that allows to change
+between free wheel mode and ratchet mode. When the switch is ratchet
+mode (ON state), the wheel will offer some resistance for movements. It
+may also provide a tactile feedback when scrolled.
+
+Note that some mice have a ratchet switch that does not generate a
+software event.
+
EV_MSC:
--
EV_MSC events are used for input and output events that do not fall under other
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index a3e8c572a046..79dd7dbf5442 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -292,7 +292,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x0f
+#define INPUT_DEVICE_ID_SW_MAX 0x1f
#define INPUT_DEVICE_ID_MATCH_BUS 1
#define INPUT_DEVICE_ID_MATCH_VENDOR 2
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index da48d4079511..da83e231e93d 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -789,7 +789,9 @@
#define SW_LINEIN_INSERT 0x0d /* set = inserted */
#define SW_MUTE_DEVICE 0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
-#define SW_MAX 0x0f
+#define SW_RATCHET 0x10 /* set = ratchet mode,
+unset: free wheel */
+#define SW_MAX 0x1f
#define SW_CNT (SW_MAX+1)
/*
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/5] input: add an EV_REL event for high-res vertical wheel
As some devices can produce either low-res or high-res vertical wheel EV_REL events, add a new event to allow userspace to distinguish between them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/input/event-codes.txt| 17 ++--- include/uapi/linux/input-event-codes.h | 1 + 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt index 575415f4cef0..50352ab5f6d4 100644 --- a/Documentation/input/event-codes.txt +++ b/Documentation/input/event-codes.txt @@ -156,9 +156,20 @@ instead of EV_REL codes. A few EV_REL codes have special meanings: -* REL_WHEEL, REL_HWHEEL: - - These codes are used for vertical and horizontal scroll wheels, -respectively. +* REL_WHEEL: + + - These codes are used for vertical scroll wheels. + + - REL_WHEEL is for normal wheel operational mode, e. g. low-resolution +(line-based) scroll. + + - REL_HIRES_WHEEL should be used when the wheel has two resolutions and it +is in high-resolution mode, e. g. the same angular movement that would +produce a single REL_WHEEL will produce multiple REL_HIRES_WHEEL events. + +* REL_HWHEEL: + + - This code is used for horizontal scroll wheels. EV_ABS: -- diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 444956ba832c..da48d4079511 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -710,6 +710,7 @@ #define REL_MISC_4 0x0d #define REL_MISC_5 0x0e #define REL_MISC_6 0x0f +#define REL_HIRES_WHEEL0x10 #define REL_MAX0x1f #define REL_CNT(REL_MAX+1) -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Tue, Apr 11, 2017 at 12:33:35PM +0100, Catalin Marinas wrote: > On Mon, Apr 10, 2017 at 11:47:40PM +0400, Yury Norov wrote: > > According to latest plans figured out on Linaro Connect, ILP32 should > > be taken in 4.12 merge window. > > Sorry, I wasn't present at Linaro Connect, so definitely not involved in > such decision. > > BTW, it would be nice to have Arnd's ack on patch 2 (32-bit ABI: > introduce ARCH_32BIT_OFF_T config option). He already acked it, but after some rebase I lost that line http://lists-archives.com/linux-kernel/28471253-32-bit-abi-introduce-arch_32bit_off_t-config-option.html Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] devicetree: Document the max31760 device binding.
> On Apr 10, 2017, at 8:42 AM, Rob Herring wrote: > > On Tue, Apr 04, 2017 at 12:20:34PM -0700, John Muir wrote: >> +MAX31760 fan controller >> +--- >> + >> +This device supports I2C only. Many properties of this device are >> configurable >> +thorugh the hwmon interface. See also Documentation/hwmon/max31760. > > I really think we need to describe the fans as separate nodes and > preferably with a common binding. This is the second fan controller > binding recently[1]. > > Features of the "hwmon interface" are not relevant to the binding. > Bindings describe h/w. It seems to me that referring to the hwmon interface is only helpful. You are suggesting removing those sentences? If so, can I add a link to the data sheet? > >> +Optional node properties: >> +- maxim,fan1-enabled- 1 to enable, 0 to disable. Default: 1. >> +- maxim,fan2-enabled- 1 to enable, 0 to disable. Default: 1. >> +- maxim,fan1-label - String: Hwmon fan1_label. >> +- maxim,fan2-label - String: Hwmon fan2_label. > > Perhaps 2 fan sub nodes. reg for fan number, status for enabled, and > label for label. OK. Right now a fan’s number of pulses and the PWM frequency are configured using the hwmon sysfs interface (which defines standard controls for those), but as those are characteristics of the hardware, should they also be configured via the device tree binding? >> +- maxim,pwm-zero-fan-can-fail - 0: Fan failure detection disabled >> when PWM is >> + ramping to 0%. >> + 1: Fan failure detection enabled for all PWM >> + values. >> + Default: 0. > > All these can be boolean… OK. The only issue I see is when the default is ‘true’ in the device, but I’ll try to avoid that. Sometimes I wish that you could set a boolean to false in DTS files. > >> +- maxim,temp1-label - String: Hwmon temp1_label. >> +- maxim,temp2-label - String: Hwmon temp2_label. >> +- maxim,temp2-ideality - Set ideality factor for the remote >> temperature >> + sensor. Integer with range 0 to 63, >> + representing a multiplication factor of 0.9844 >> + to 1.0489. Default: 24 (1.0080). > > No maxim,temp1-ideality? No - the device only lets you set the ideality of the ‘external' temperature sensor. I guess if there is an ideality for the internal temperature sensor, it would be hard-wired as a characteristic of the part that was used. > Not sure what to do with these, but perhaps > also as sub-nodes. Surely we have some bindings already for devices with > multiple temp sensors. Don't invent something custom here. I’ll look into it. What is the best way to distinguish between ‘fan’ and ‘temp’ sub-nodes? Do I require a ‘compatible’ string? Thanks! John. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > On Wed, 5 Apr 2017 10:22:54 -0300 > > Mauro Carvalho Chehab wrote: > > > > > Currently, there are several USB core documents that are at either > > > written in plain text or in DocBook format. Convert them to ReST > > > and add to the driver-api book. > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > touch comments outside of Documentation/; I'm happy to carry those or > > leave them to you, as you prefer. > > I'll queue them up in the next few days, thanks! Nope, they don't apply to my tree, it was probably based on yours. And the first two are ones I shouldn't be taking. So, feel free to take all of these with a: Acked-by: Greg Kroah-Hartman for the USB-related patches (2-21). thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] dm: boot a mapped device without an initramfs
Hello, Some of these patches were send few years back, I saw that first version was send to this list in 2010, and after some reviews did not landi [1] , apparently without any reason. The patches has been used and working well on the ChromeOS kernel for long time, this version is basically a rebase on top of mainline based on latest version found in chromeos 4.4 kernel, the patches has also been tested on a veyron device. This a new attempt to try to land these patches again, so I'll wait for comments/reviews and send new version to the list. [1] Patchwork links: https://patchwork.kernel.org/patch/104857/ https://patchwork.kernel.org/patch/104856/ https://patchwork.kernel.org/patch/104858/ Best regards, Enric Brian Norris (1): dm: move dm_table_destroy() to same header as dm_table_create() Enric Balletbo i Serra (1): dm: move dm definitions outside the private header to boot dm targets. Will Drewry (3): dm: export a table+mapped device to the ioctl interface init: add support to directly boot to a mapped device dm verity: add support for version 0 of the on-disk format Documentation/admin-guide/kernel-parameters.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 3 + Documentation/device-mapper/boot.txt| 42 +++ drivers/md/dm-ioctl.c | 39 ++ drivers/md/dm-verity-target.c | 279 ++ drivers/md/dm.h | 8 - include/linux/device-mapper.h | 19 + init/Makefile | 1 + init/do_mounts.c| 1 + init/do_mounts.h| 10 + init/do_mounts_dm.c | 472 11 files changed, 803 insertions(+), 72 deletions(-) create mode 100644 Documentation/device-mapper/boot.txt create mode 100644 init/do_mounts_dm.c -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] dm: move dm_table_destroy() to same header as dm_table_create()
From: Brian Norris If anyone is going to use dm_table_create(), they probably should be able to use dm_table_destroy() too. Move the dm_table_destroy() definition outside the private header, near dm_table_create() Signed-off-by: Brian Norris Signed-off-by: Enric Balletbo i Serra --- drivers/md/dm.h | 1 - include/linux/device-mapper.h | 5 + 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/md/dm.h b/drivers/md/dm.h index f298b01..c54d2f1 100644 --- a/drivers/md/dm.h +++ b/drivers/md/dm.h @@ -48,7 +48,6 @@ struct dm_md_mempools; /*- * Internal table functions. *---*/ -void dm_table_destroy(struct dm_table *t); void dm_table_event_callback(struct dm_table *t, void (*fn)(void *), void *context); struct dm_target *dm_table_get_target(struct dm_table *t, unsigned int index); diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h index a7e6903..70cb6af 100644 --- a/include/linux/device-mapper.h +++ b/include/linux/device-mapper.h @@ -472,6 +472,11 @@ void dm_table_set_type(struct dm_table *t, unsigned type); int dm_table_complete(struct dm_table *t); /* + * Destroy the table when finished. + */ +void dm_table_destroy(struct dm_table *t); + +/* * Target may require that it is never sent I/O larger than len. */ int __must_check dm_set_target_max_io_len(struct dm_target *ti, sector_t len); -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] dm verity: add support for version 0 of the on-disk format
From: Will Drewry
Version 0 of the on-disk format is compatible with the format used in the
Chromium OS. This patch adds support for this version.
Format type 0 is the original Chrome OS version, whereas the format type 1
is current version, but 0, the original format used in the Chromium OS is
still used in most devices. This patch adds support for the original
on-disk format so you can decide which want you want to use.
Signed-off-by: Will Drewry
Signed-off-by: Enric Balletbo i Serra
---
drivers/md/dm-verity-target.c | 279 --
init/do_mounts_dm.c | 16 +--
2 files changed, 220 insertions(+), 75 deletions(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 7335d8a..c098d22 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -17,6 +17,7 @@
#include "dm-verity.h"
#include "dm-verity-fec.h"
+#include
#include
#include
@@ -28,6 +29,7 @@
#define DM_VERITY_DEFAULT_PREFETCH_SIZE262144
#define DM_VERITY_MAX_CORRUPTED_ERRS 100
+#define DM_VERITY_NUM_POSITIONAL_ARGS 10
#define DM_VERITY_OPT_LOGGING "ignore_corruption"
#define DM_VERITY_OPT_RESTART "restart_on_corruption"
@@ -46,6 +48,11 @@ struct dm_verity_prefetch_work {
unsigned n_blocks;
};
+/* Controls whether verity_get_device will wait forever for a device. */
+static int dev_wait;
+module_param(dev_wait, int, 0444);
+MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
+
/*
* Auxiliary structure appended to each dm-bufio buffer. If the value
* hash_verified is nonzero, hash of the block has been verified.
@@ -803,6 +810,183 @@ static int verity_parse_opt_args(struct dm_arg_set *as,
struct dm_verity *v)
return r;
}
+static int verity_get_device(struct dm_target *ti, const char *devname,
+struct dm_dev **dm_dev)
+{
+ do {
+ /* Try the normal path first since if everything is ready, it
+* will be the fastest.
+*/
+ if (!dm_get_device(ti, devname, /*FMODE_READ*/
+ dm_table_get_mode(ti->table), dm_dev))
+ return 0;
+
+ if (!dev_wait)
+ break;
+
+ /* No need to be too aggressive since this is a slow path. */
+ msleep(500);
+ } while (driver_probe_done() != 0 || !(*dm_dev));
+ return -1;
+}
+
+struct verity_args {
+ int version;
+ char *data_device;
+ char *hash_device;
+ int data_block_size_bits;
+ int hash_block_size_bits;
+ u64 num_data_blocks;
+ u64 hash_start_block;
+ char *algorithm;
+ char *digest;
+ char *salt;
+};
+
+static void pr_args(struct verity_args *args)
+{
+ printk(KERN_INFO "VERITY args: version=%d data_device=%s hash_device=%s"
+ " data_block_size_bits=%d hash_block_size_bits=%d"
+ " num_data_blocks=%lld hash_start_block=%lld"
+ " algorithm=%s digest=%s salt=%s\n",
+ args->version,
+ args->data_device,
+ args->hash_device,
+ args->data_block_size_bits,
+ args->hash_block_size_bits,
+ args->num_data_blocks,
+ args->hash_start_block,
+ args->algorithm,
+ args->digest,
+ args->salt);
+}
+
+/*
+ * positional_args - collects the argments using the positional
+ * parameters.
+ * arg# - parameter
+ *0 - version
+ *1 - data device
+ *2 - hash device - may be same as data device
+ *3 - data block size log2
+ *4 - hash block size log2
+ *5 - number of data blocks
+ *6 - hash start block
+ *7 - algorithm
+ *8 - digest
+ *9 - salt
+ */
+static char *positional_args(unsigned argc, char **argv,
+struct verity_args *args)
+{
+ unsigned int num;
+ unsigned long long num_ll;
+ char dummy;
+
+ if (argc < DM_VERITY_NUM_POSITIONAL_ARGS)
+ return "Invalid argument count: at least 10 arguments required";
+
+ if (sscanf(argv[0], "%d%c", &num, &dummy) != 1 ||
+ num < 0 || num > 1)
+ return "Invalid version";
+ args->version = num;
+
+ args->data_device = argv[1];
+ args->hash_device = argv[2];
+
+ if (sscanf(argv[3], "%u%c", &num, &dummy) != 1 ||
+ !num || (num & (num - 1)) ||
+ num > PAGE_SIZE)
+ return "Invalid data device block size";
+ args->data_block_size_bits = ffs(num) - 1;
+
+ if (sscanf(argv[4], "%u%c", &num, &dummy) != 1 ||
+ !num || (num & (num - 1)) ||
+ num > INT_MAX)
+ return "Invalid hash device block size";
+ args->hash_block_size_bits = ffs(num) - 1;
+
+ if (sscanf(argv[5], "%llu%c", &num_ll, &dummy) != 1 ||
+ (sector_t)(num_
[PATCH 3/5] dm: export a table+mapped device to the ioctl interface
From: Will Drewry
One function is added which allows for a programmatically created
mapped device to be inserted into the dm-ioctl hash table. This binds
the device to a name and, optional, uuid which is needed by udev and
allows for userspace management of the mapped device.
Signed-off-by: Will Drewry
Signed-off-by: Enric Balletbo i Serra
---
drivers/md/dm-ioctl.c | 39 +++
include/linux/device-mapper.h | 6 ++
2 files changed, 45 insertions(+)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 4da6fc6..cdd7a14 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1929,6 +1929,45 @@ void dm_interface_exit(void)
}
/**
+ * dm_ioctl_export - Permanently export a mapped device via the ioctl interface
+ * @md: Pointer to mapped_device
+ * @name: Buffer (size DM_NAME_LEN) for name
+ * @uuid: Buffer (size DM_UUID_LEN) for uuid or NULL if not desired
+ */
+int dm_ioctl_export(struct mapped_device *md, const char *name,
+ const char *uuid)
+{
+ int r = 0;
+ struct hash_cell *hc;
+
+ if (!md) {
+ r = -ENXIO;
+ goto out;
+ }
+
+ /* The name and uuid can only be set once. */
+ mutex_lock(&dm_hash_cells_mutex);
+ hc = dm_get_mdptr(md);
+ mutex_unlock(&dm_hash_cells_mutex);
+ if (hc) {
+ DMERR("%s: already exported", dm_device_name(md));
+ r = -ENXIO;
+ goto out;
+ }
+
+ r = dm_hash_insert(name, uuid, md);
+ if (r) {
+ DMERR("%s: could not bind to '%s'", dm_device_name(md), name);
+ goto out;
+ }
+
+ /* Let udev know we've changed. */
+ dm_kobject_uevent(md, KOBJ_CHANGE, dm_get_event_nr(md));
+out:
+ return r;
+}
+
+/**
* dm_copy_name_and_uuid - Copy mapped device name & uuid into supplied buffers
* @md: Pointer to mapped_device
* @name: Buffer (size DM_NAME_LEN) for name
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 013ac2e..b60892e 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -405,6 +405,12 @@ void dm_set_mdptr(struct mapped_device *md, void *ptr);
void *dm_get_mdptr(struct mapped_device *md);
/*
+ * Export the device via the ioctl interface (uses mdptr).
+ */
+int dm_ioctl_export(struct mapped_device *md, const char *name,
+ const char *uuid);
+
+/*
* A device can still be used while suspended, but I/O is deferred.
*/
int dm_suspend(struct mapped_device *md, unsigned suspend_flags);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] init: add support to directly boot to a mapped device
From: Will Drewry
Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise).
Signed-off-by: Will Drewry
Signed-off-by: Enric Balletbo i Serra
---
Documentation/admin-guide/kernel-parameters.rst | 1 +
Documentation/admin-guide/kernel-parameters.txt | 3 +
Documentation/device-mapper/boot.txt| 42 +++
init/Makefile | 1 +
init/do_mounts.c| 1 +
init/do_mounts.h| 10 +
init/do_mounts_dm.c | 478
7 files changed, 536 insertions(+)
create mode 100644 Documentation/device-mapper/boot.txt
create mode 100644 init/do_mounts_dm.c
diff --git a/Documentation/admin-guide/kernel-parameters.rst
b/Documentation/admin-guide/kernel-parameters.rst
index b516164..ecb58d6 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -91,6 +91,7 @@ parameter is applicable::
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
CMA Contiguous Memory Area support is enabled.
+ DM Device mapper support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..686453d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -830,6 +830,9 @@
dis_ucode_ldr [X86] Disable the microcode loader.
+ dm= [DM] Allows early creation of a device-mapper device.
+ See Documentation/device-mapper/boot.txt.
+
dma_debug=off If the kernel is compiled with DMA_API_DEBUG support,
this option disables the debugging code at boot.
diff --git a/Documentation/device-mapper/boot.txt
b/Documentation/device-mapper/boot.txt
new file mode 100644
index 000..76ea6ac
--- /dev/null
+++ b/Documentation/device-mapper/boot.txt
@@ -0,0 +1,42 @@
+Boot time creation of mapped devices
+===
+
+It is possible to configure a device mapper device to act as the root
+device for your system in two ways.
+
+The first is to build an initial ramdisk which boots to a minimal
+userspace which configures the device, then pivot_root(8) in to it.
+
+For simple device mapper configurations, it is possible to boot directly
+using the following kernel command line:
+
+dm=" ,table line 1,...,table line n"
+
+name = the name to associate with the device
+ after boot, udev, if used, will use that name to label
+ the device node.
+uuid = may be 'none' or the UUID desired for the device.
+ro = may be 'ro' or 'rw'. If 'ro', the device and device table will be
+ marked read-only.
+
+Each table line may be as normal when using the dmsetup tool except for
+two variations:
+1. Any use of commas will be interpreted as a newline
+2. Quotation marks cannot be escaped and cannot be used without
+ terminating the dm= argument.
+
+Unless renamed by udev, the device node created will be dm-0 as the
+first minor number for the device-mapper is used during early creation.
+
+Example
+===
+
+- Booting to a linear array made up of user-mode linux block devices:
+
+ dm="lroot none 0, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \
+ root=/dev/dm-0
+
+Will boot to a rw dm-linear target of 8192 sectors split across two
+block devices identified by their major:minor numbers. After boot, udev
+will rename this target to /dev/mapper/lroot (depending on the rules).
+No uuid was assigned.
diff --git a/init/Makefile b/init/Makefile
index c4fb455..30424d7 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -20,6 +20,7 @@ mounts-y := do_mounts.o
mounts-$(CONFIG_BLK_DEV_RAM) += do_mounts_rd.o
mounts-$(CONFIG_BLK_DEV_INITRD)+= do_mounts_initrd.o
mounts-$(CONFIG_BLK_DEV_MD)+= do_mounts_md.o
+mounts-$(CONFIG_BLK_DEV_DM)+= do_mounts_dm.o
# dependencies on generated files need to be listed explicitly
$(obj)/version.o: include/generated/compile.h
diff --git a/init/do_mounts.c b/init/do_mounts.c
index c2de510..8b9182b 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -566,6 +566,7 @@ void __init prepare_namespace(void)
wait_for_device_probe();
md_run_setup();
+ dm_run_setup();
if (saved_root_name[0]) {
root_device_name = saved_root_name;
diff --git a/init/do_mounts.h b/init/do_mounts.h
index 067af1d..ecb2757 100644
--- a/init/do_mounts.h
+++ b/init/do_mounts.h
@@ -74,3 +74,
[PATCH 2/5] dm: move dm definitions outside the private header to boot dm targets.
To boot to device-mapper targets without an initr* we should be able to use some dm functions, move these to the device-mapper include file so we can call these functions from init/* The functions moved are: dm_table_get_type() dm_lock_md_type() dm_unlock_md_type() dm_set_md_type() dm_get_md_type() dm_setup_md_queue() Signed-off-by: Enric Balletbo i Serra --- drivers/md/dm.h | 7 --- include/linux/device-mapper.h | 8 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/md/dm.h b/drivers/md/dm.h index c54d2f1..6b501b5 100644 --- a/drivers/md/dm.h +++ b/drivers/md/dm.h @@ -63,7 +63,6 @@ void dm_table_presuspend_undo_targets(struct dm_table *t); void dm_table_postsuspend_targets(struct dm_table *t); int dm_table_resume_targets(struct dm_table *t); int dm_table_any_congested(struct dm_table *t, int bdi_bits); -unsigned dm_table_get_type(struct dm_table *t); struct target_type *dm_table_get_immutable_target_type(struct dm_table *t); struct dm_target *dm_table_get_immutable_target(struct dm_table *t); struct dm_target *dm_table_get_wildcard_target(struct dm_table *t); @@ -73,14 +72,8 @@ bool dm_table_all_blk_mq_devices(struct dm_table *t); void dm_table_free_md_mempools(struct dm_table *t); struct dm_md_mempools *dm_table_get_md_mempools(struct dm_table *t); -void dm_lock_md_type(struct mapped_device *md); -void dm_unlock_md_type(struct mapped_device *md); -void dm_set_md_type(struct mapped_device *md, unsigned type); -unsigned dm_get_md_type(struct mapped_device *md); struct target_type *dm_get_immutable_target_type(struct mapped_device *md); -int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t); - /* * To check the return value from dm_table_find_target(). */ diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h index 70cb6af..013ac2e 100644 --- a/include/linux/device-mapper.h +++ b/include/linux/device-mapper.h @@ -513,6 +513,14 @@ void dm_table_run_md_queue_async(struct dm_table *t); struct dm_table *dm_swap_table(struct mapped_device *md, struct dm_table *t); +unsigned dm_table_get_type(struct dm_table *t); + +void dm_lock_md_type(struct mapped_device *md); +void dm_unlock_md_type(struct mapped_device *md); +void dm_set_md_type(struct mapped_device *md, unsigned type); +unsigned dm_get_md_type(struct mapped_device *md); +int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t); + /* * A wrapper around vmalloc. */ -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] kvm: better MWAIT emulation for guests
This might be more useful if it could be dynamically toggled on and off, depending on system load. On Tue, Apr 11, 2017 at 4:45 AM, Alexander Graf wrote: > From: "Michael S. Tsirkin" > > Guests that are heavy on futexes end up IPI'ing each other a lot. That > can lead to significant slowdowns and latency increase for those guests > when running within KVM. > > If only a single guest is needed on a host, we have a lot of spare host > CPU time we can throw at the problem. Modern CPUs implement a feature > called "MWAIT" which allows guests to wake up sleeping remote CPUs without > an IPI - thus without an exit - at the expense of never going out of guest > context. > > The decision whether this is something sensible to use should be up to the > VM admin, so to user space. We can however allow MWAIT execution on systems > that support it properly hardware wise. > > This patch adds a CAP to user space and a KVM cpuid leaf to indicate > availability of native MWAIT execution. With that enabled, the worst a > guest can do is waste as many cycles as a "jmp ." would do, so it's not > a privilege problem. > > We consciously do *not* expose the feature in our CPUID bitmap, as most > people will want to benefit from sleeping vCPUs to allow for over commit. > > Reported-by: "Gabriel L. Somlo" > Signed-off-by: Michael S. Tsirkin > [agraf: fix amd, change commit message] > Signed-off-by: Alexander Graf > > --- > > v5 -> v6: > > - Fix AMD check, so that we're consistent between svm and vmx > - Clarify commit message > --- > Documentation/virtual/kvm/api.txt| 9 + > Documentation/virtual/kvm/cpuid.txt | 6 ++ > arch/x86/include/uapi/asm/kvm_para.h | 1 + > arch/x86/kvm/cpuid.c | 3 +++ > arch/x86/kvm/svm.c | 7 +-- > arch/x86/kvm/vmx.c | 6 -- > arch/x86/kvm/x86.c | 3 +++ > arch/x86/kvm/x86.h | 36 > > include/uapi/linux/kvm.h | 1 + > 9 files changed, 68 insertions(+), 4 deletions(-) > > diff --git a/Documentation/virtual/kvm/api.txt > b/Documentation/virtual/kvm/api.txt > index 1a18484..dacc3d7 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -4094,3 +4094,12 @@ reserved. > 2: MIPS64 or microMIPS64 with access to all address segments. > Both registers and addresses are 64-bits wide. > It will be possible to run 64-bit or 32-bit guest code. > + > +8.8 KVM_CAP_X86_GUEST_MWAIT > + > +Architectures: x86 > + > +This capability indicates that guest using memory monotoring instructions > +(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit. As such > time > +spent while virtual CPU is halted in this way will then be accounted for as > +guest running time on the host (as opposed to e.g. HLT). > diff --git a/Documentation/virtual/kvm/cpuid.txt > b/Documentation/virtual/kvm/cpuid.txt > index 3c65feb..04c201c 100644 > --- a/Documentation/virtual/kvm/cpuid.txt > +++ b/Documentation/virtual/kvm/cpuid.txt > @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT || 7 || guest > checks this feature bit > || || before enabling > paravirtualized > || || spinlock support. > > -- > +KVM_FEATURE_MWAIT || 8 || guest can use monitor/mwait > + || || to halt the VCPU without > exits, > + || || time spent while halted in > this > + || || way is accounted for on host > as > + || || VCPU run time. > +-- > KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no > guest-side > || || per-cpu warps are expected in > || || kvmclock. > diff --git a/arch/x86/include/uapi/asm/kvm_para.h > b/arch/x86/include/uapi/asm/kvm_para.h > index cff0bb6..9cc77a7 100644 > --- a/arch/x86/include/uapi/asm/kvm_para.h > +++ b/arch/x86/include/uapi/asm/kvm_para.h > @@ -24,6 +24,7 @@ > #define KVM_FEATURE_STEAL_TIME 5 > #define KVM_FEATURE_PV_EOI 6 > #define KVM_FEATURE_PV_UNHALT 7 > +#define KVM_FEATURE_MWAIT 8 > > /* The last 8 bits are used to indicate how to interpret the flags field > * in pvclock structure. If no bits are set, all flags are ignored. > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index efde6cc..5638102 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 > *entry, u32 function, > if (sched_info_on()) >
Re: [PATCH 5/5] dm verity: add support for version 0 of the on-disk format
On 04/11/2017 05:33 PM, Enric Balletbo i Serra wrote:
> From: Will Drewry
>
> Version 0 of the on-disk format is compatible with the format used in the
> Chromium OS. This patch adds support for this version.
>
> Format type 0 is the original Chrome OS version, whereas the format type 1
> is current version, but 0, the original format used in the Chromium OS is
> still used in most devices. This patch adds support for the original
> on-disk format so you can decide which want you want to use.
NACK!
What the ... is this patch doing?
Isn't the format 0 already there? According to
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt
This is the type of the on-disk hash format.
0 is the original format used in the Chromium OS.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeroes.
Reading this patch, it does something completely different than it describes
in header.
How is superblock format related to:
+MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
...
not mentioning complete rewrite of verity table parsing... why?
Also please note that there is userspace (veritysetup) that have to work with
the old format as well (I think it does already).
I think we solved the compatibility years ago.
If not, please describe properly what is missing.
I do not see any on-disk format changes here...
Milan
>
> Signed-off-by: Will Drewry
> Signed-off-by: Enric Balletbo i Serra
> ---
> drivers/md/dm-verity-target.c | 279
> --
> init/do_mounts_dm.c | 16 +--
> 2 files changed, 220 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
> index 7335d8a..c098d22 100644
> --- a/drivers/md/dm-verity-target.c
> +++ b/drivers/md/dm-verity-target.c
> @@ -17,6 +17,7 @@
> #include "dm-verity.h"
> #include "dm-verity-fec.h"
>
> +#include
> #include
> #include
>
> @@ -28,6 +29,7 @@
> #define DM_VERITY_DEFAULT_PREFETCH_SIZE 262144
>
> #define DM_VERITY_MAX_CORRUPTED_ERRS 100
> +#define DM_VERITY_NUM_POSITIONAL_ARGS10
>
> #define DM_VERITY_OPT_LOGGING"ignore_corruption"
> #define DM_VERITY_OPT_RESTART"restart_on_corruption"
> @@ -46,6 +48,11 @@ struct dm_verity_prefetch_work {
> unsigned n_blocks;
> };
>
> +/* Controls whether verity_get_device will wait forever for a device. */
> +static int dev_wait;
> +module_param(dev_wait, int, 0444);
> +MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
> +
> /*
> * Auxiliary structure appended to each dm-bufio buffer. If the value
> * hash_verified is nonzero, hash of the block has been verified.
> @@ -803,6 +810,183 @@ static int verity_parse_opt_args(struct dm_arg_set *as,
> struct dm_verity *v)
> return r;
> }
>
> +static int verity_get_device(struct dm_target *ti, const char *devname,
> + struct dm_dev **dm_dev)
> +{
> + do {
> + /* Try the normal path first since if everything is ready, it
> + * will be the fastest.
> + */
> + if (!dm_get_device(ti, devname, /*FMODE_READ*/
> +dm_table_get_mode(ti->table), dm_dev))
> + return 0;
> +
> + if (!dev_wait)
> + break;
> +
> + /* No need to be too aggressive since this is a slow path. */
> + msleep(500);
> + } while (driver_probe_done() != 0 || !(*dm_dev));
> + return -1;
> +}
> +
> +struct verity_args {
> + int version;
> + char *data_device;
> + char *hash_device;
> + int data_block_size_bits;
> + int hash_block_size_bits;
> + u64 num_data_blocks;
> + u64 hash_start_block;
> + char *algorithm;
> + char *digest;
> + char *salt;
> +};
> +
> +static void pr_args(struct verity_args *args)
> +{
> + printk(KERN_INFO "VERITY args: version=%d data_device=%s hash_device=%s"
> + " data_block_size_bits=%d hash_block_size_bits=%d"
> + " num_data_blocks=%lld hash_start_block=%lld"
> + " algorithm=%s digest=%s salt=%s\n",
> + args->version,
> + args->data_device,
> + args->hash_device,
> + args->data_block_size_bits,
> + args->hash_block_size_bits,
> + args->num_data_blocks,
> + args->hash_start_block,
> + args->algorithm,
> + args->digest,
> + args->salt);
> +}
> +
> +/*
> + * positional_args - collects the argments using the positional
> + * parameters.
> + * arg# - parameter
> + *0 - version
> + *1 - data device
> + *2 - hash device - may be same as data device
> + *3 - data block size log2
> + *4 - hash block size log2
> + *5 - number of data blocks
> + *6 - hash star
Re: [PATCH v6] kvm: better MWAIT emulation for guests
> Am 11.04.2017 um 19:10 schrieb Jim Mattson : > > This might be more useful if it could be dynamically toggled on and > off, depending on system load. What would trapping mwait (currently) buy you? As it stands today, before this patch, mwait is simply implemented as a nop, so enabling the trap just means you're wasting as much cpu time, but never send the pCPU idle. With this patch, the CPU at least has the chance to go idle. Keep in mind that this patch does *not* advertise the mwait cpuid feature bit to the guest. What you're referring to I guess is actual mwait emulation. That is indeed more useful, but a bigger patch than this and needs some more thought on how to properly cache the monitor'ed pages. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
Em Tue, 11 Apr 2017 16:58:40 +0200 Greg Kroah-Hartman escreveu: > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > > On Wed, 5 Apr 2017 10:22:54 -0300 > > > Mauro Carvalho Chehab wrote: > > > > > > > Currently, there are several USB core documents that are at either > > > > written in plain text or in DocBook format. Convert them to ReST > > > > and add to the driver-api book. > > > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > > touch comments outside of Documentation/; I'm happy to carry those or > > > leave them to you, as you prefer. > > > > I'll queue them up in the next few days, thanks! > > Nope, they don't apply to my tree, it was probably based on yours. And > the first two are ones I shouldn't be taking. Yeah, I based it at the docs-next tree. If you prefer, I can rebase on your tree, but I guess that the docbook conversion patches would likely conflict with some patches at docs-next, because of the Makefile changes. > So, feel free to take all of these with a: > Acked-by: Greg Kroah-Hartman > for the USB-related patches (2-21). > > thanks, > > greg k-h Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
> Also, the latest benchmarks I've seen were mostly for user space > while I'm more concerned with the user-kernel interface > (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). > On the glibc testing side, have the regressions been identified/fixed? I run LTP for testing the ABI and kernel, and there is no failures in ltplite scenario. With glibc testsuite, there's only 3 failures comparing to lp64. (Steve, fix me if something changed.) This is slides on ilp32 from Linaro Connect, hope you'll find it useful. https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
On Tue, Apr 11, 2017 at 03:36:39PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 11 Apr 2017 16:58:40 +0200 > Greg Kroah-Hartman escreveu: > > > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote: > > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote: > > > > On Wed, 5 Apr 2017 10:22:54 -0300 > > > > Mauro Carvalho Chehab wrote: > > > > > > > > > Currently, there are several USB core documents that are at either > > > > > written in plain text or in DocBook format. Convert them to ReST > > > > > and add to the driver-api book. > > > > > > > > Greg, do you see any reason not to apply these for 4.12? A few of them > > > > touch comments outside of Documentation/; I'm happy to carry those or > > > > leave them to you, as you prefer. > > > > > > I'll queue them up in the next few days, thanks! > > > > Nope, they don't apply to my tree, it was probably based on yours. And > > the first two are ones I shouldn't be taking. > > Yeah, I based it at the docs-next tree. If you prefer, I can rebase > on your tree, but I guess that the docbook conversion patches > would likely conflict with some patches at docs-next, because of > the Makefile changes. Doesn't bother me, it can go through the Documentation tree as-is. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On 04/11/2017 08:36 PM, Yury Norov wrote: Also, the latest benchmarks I've seen were mostly for user space while I'm more concerned with the user-kernel interface (https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2). On the glibc testing side, have the regressions been identified/fixed? I run LTP for testing the ABI and kernel, and there is no failures in ltplite scenario. With glibc testsuite, there's only 3 failures comparing to lp64. (Steve, fix me if something changed.) This is slides on ilp32 from Linaro Connect, hope you'll find it useful. https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing The listed failures are: misc/tst-sync_file_range nptl/tst-stack4 malloc/tst-mallocstate If necessary, I will fix malloc/tst-mallocstate once there's support for a new architecture in build-many-glibcs.py. The failure is architecture-independent, it's related to the lack of a compat symbol and the difficulty of checking for that at the Makefile or test level. nptl/tst-stack4 is also a generic failure, I think. misc/tst-sync_file_range is probably a real failure related to argument passing. I think this system call was problematic on other architectures, too. Thanks, Florian (Sorry for the wide Cc: list despite the glibc content.) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] PCI: Support for configurable PCI endpoint
On Mon, Apr 10, 2017 at 10:43:28AM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 05, 2017 at 02:22:20PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Bjorn,
> >
> > Please find the pull request for PCI endpoint support below. I've
> > also included all the history here.
>
> Thanks, I applied these (with v7 of the first patch) to pci/host-designware
> for v4.12.
Ok, sorry, I screwed this up. I think my branch actually had v5, not
v6. But I *think* I fixed it. Here's the diff from my branch to your
git tree. Apparently you haven't pushed the v7 patch there, so I
*think* the diff below is the diff between v6 and v7 of that first
patch.
$ git diff pci/host-designware a5c85ba45c96
diff --git a/drivers/pci/endpoint/pci-epc-core.c
b/drivers/pci/endpoint/pci-epc-core.c
index caa7be10e473..9ae9e59b2a74 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -83,7 +83,6 @@ struct pci_epc *pci_epc_get(const char *epc_name)
goto err;
}
- class_dev_iter_exit(&iter);
get_device(&epc->dev);
return epc;
}
diff --git a/drivers/pci/endpoint/pci-epf-core.c
b/drivers/pci/endpoint/pci-epf-core.c
index 6877d6a5bcc9..92db7dcd911c 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -40,10 +40,8 @@ static struct device_type pci_epf_type;
*/
void pci_epf_linkup(struct pci_epf *epf)
{
- if (!epf->driver) {
+ if (!epf->driver)
dev_WARN(&epf->dev, "epf device not bound to driver\n");
- return;
- }
epf->driver->ops->linkup(epf);
}
@@ -59,10 +57,8 @@ EXPORT_SYMBOL_GPL(pci_epf_linkup);
*/
void pci_epf_unbind(struct pci_epf *epf)
{
- if (!epf->driver) {
+ if (!epf->driver)
dev_WARN(&epf->dev, "epf device not bound to driver\n");
- return;
- }
epf->driver->ops->unbind(epf);
module_put(epf->driver->owner);
@@ -78,10 +74,8 @@ EXPORT_SYMBOL_GPL(pci_epf_unbind);
*/
int pci_epf_bind(struct pci_epf *epf)
{
- if (!epf->driver) {
+ if (!epf->driver)
dev_WARN(&epf->dev, "epf device not bound to driver\n");
- return -EINVAL;
- }
if (!try_module_get(epf->driver->owner))
return -EAGAIN;
@@ -233,7 +227,7 @@ struct pci_epf *pci_epf_create(const char *name)
epf->name = kstrdup(func_name, GFP_KERNEL);
if (!epf->name) {
ret = -ENOMEM;
- goto free_func_name;
+ goto free_epf;
}
dev = &epf->dev;
@@ -255,8 +249,6 @@ struct pci_epf *pci_epf_create(const char *name)
put_dev:
put_device(dev);
kfree(epf->name);
-
-free_func_name:
kfree(func_name);
free_epf:
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] dm verity: add support for version 0 of the on-disk format
On 11/04/17 19:21, Milan Broz wrote:
> On 04/11/2017 05:33 PM, Enric Balletbo i Serra wrote:
>> From: Will Drewry
>>
>> Version 0 of the on-disk format is compatible with the format used in the
>> Chromium OS. This patch adds support for this version.
>>
>> Format type 0 is the original Chrome OS version, whereas the format type 1
>> is current version, but 0, the original format used in the Chromium OS is
>> still used in most devices. This patch adds support for the original
>> on-disk format so you can decide which want you want to use.
>
> NACK!
>
> What the ... is this patch doing?
>
Argh! Very sorry about that was *not* my intention add this patch in this
series, I was only trying to submit 1 to 4 which contains the patches already
send long time ago and the patches to move to the public header some functions
needed for init/do_mount_dm.c
I'm using this specific patch to test 1 to 4 and to boot against a chromeos
rootfs as it parses the current chromeos args, this patch also has the use of
some deprecated functions like simple_strtoull, so definitely this *shouldn't*
be here, my bad.
Besides that, with the below comments, you have made me see that I have some
lacks and I need to rethink some things that I wanted to send after this series,
so many thanks and sorry again if you spend some time looking at this.
> Isn't the format 0 already there? According to
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt
>
>
> This is the type of the on-disk hash format.
>
> 0 is the original format used in the Chromium OS.
> The salt is appended when hashing, digests are stored continuously and
> the rest of the block is padded with zeroes.
>
> Reading this patch, it does something completely different than it describes
> in header.
>
> How is superblock format related to:
> +MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
> ...
> not mentioning complete rewrite of verity table parsing... why?
>
> Also please note that there is userspace (veritysetup) that have to work with
> the old format as well (I think it does already).
> I think we solved the compatibility years ago.
>
> If not, please describe properly what is missing.
> I do not see any on-disk format changes here...
>
> Milan
>
>>
>> Signed-off-by: Will Drewry
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>> drivers/md/dm-verity-target.c | 279
>> --
>> init/do_mounts_dm.c | 16 +--
>> 2 files changed, 220 insertions(+), 75 deletions(-)
>>
>> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
>> index 7335d8a..c098d22 100644
>> --- a/drivers/md/dm-verity-target.c
>> +++ b/drivers/md/dm-verity-target.c
>> @@ -17,6 +17,7 @@
>> #include "dm-verity.h"
>> #include "dm-verity-fec.h"
>>
>> +#include
>> #include
>> #include
>>
>> @@ -28,6 +29,7 @@
>> #define DM_VERITY_DEFAULT_PREFETCH_SIZE 262144
>>
>> #define DM_VERITY_MAX_CORRUPTED_ERRS100
>> +#define DM_VERITY_NUM_POSITIONAL_ARGS 10
>>
>> #define DM_VERITY_OPT_LOGGING "ignore_corruption"
>> #define DM_VERITY_OPT_RESTART "restart_on_corruption"
>> @@ -46,6 +48,11 @@ struct dm_verity_prefetch_work {
>> unsigned n_blocks;
>> };
>>
>> +/* Controls whether verity_get_device will wait forever for a device. */
>> +static int dev_wait;
>> +module_param(dev_wait, int, 0444);
>> +MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
>> +
>> /*
>> * Auxiliary structure appended to each dm-bufio buffer. If the value
>> * hash_verified is nonzero, hash of the block has been verified.
>> @@ -803,6 +810,183 @@ static int verity_parse_opt_args(struct dm_arg_set
>> *as, struct dm_verity *v)
>> return r;
>> }
>>
>> +static int verity_get_device(struct dm_target *ti, const char *devname,
>> + struct dm_dev **dm_dev)
>> +{
>> +do {
>> +/* Try the normal path first since if everything is ready, it
>> + * will be the fastest.
>> + */
>> +if (!dm_get_device(ti, devname, /*FMODE_READ*/
>> + dm_table_get_mode(ti->table), dm_dev))
>> +return 0;
>> +
>> +if (!dev_wait)
>> +break;
>> +
>> +/* No need to be too aggressive since this is a slow path. */
>> +msleep(500);
>> +} while (driver_probe_done() != 0 || !(*dm_dev));
>> +return -1;
>> +}
>> +
>> +struct verity_args {
>> +int version;
>> +char *data_device;
>> +char *hash_device;
>> +int data_block_size_bits;
>> +int hash_block_size_bits;
>> +u64 num_data_blocks;
>> +u64 hash_start_block;
>> +char *algorithm;
>> +char *digest;
>> +char *salt;
>> +};
>> +
>> +static void pr_args(struct verity_args *args)
>> +{
>> +printk(KERN_INFO "VERITY args: version=%d data_devi
Re: [PATCH 2/2] devicetree: Document the max31760 device binding.
On Tue, Apr 11, 2017 at 06:47:28AM -0700, John Muir wrote: > > On Apr 10, 2017, at 8:42 AM, Rob Herring wrote: > > > > On Tue, Apr 04, 2017 at 12:20:34PM -0700, John Muir wrote: > >> +MAX31760 fan controller > >> +--- > >> + > >> +This device supports I2C only. Many properties of this device are > >> configurable > >> +thorugh the hwmon interface. See also Documentation/hwmon/max31760. > > > > I really think we need to describe the fans as separate nodes and > > preferably with a common binding. This is the second fan controller > > binding recently[1]. > > > > Features of the "hwmon interface" are not relevant to the binding. > > Bindings describe h/w. > > It seems to me that referring to the hwmon interface is only helpful. You are > suggesting removing those sentences? If so, can I add a link to the data > sheet? > Devicetree properties are supposed to be operating system independent. Any mention of how access to the device is implemented on a given operating system is out of scope for this document. Guenter > > > >> +Optional node properties: > >> +- maxim,fan1-enabled - 1 to enable, 0 to disable. Default: 1. > >> +- maxim,fan2-enabled - 1 to enable, 0 to disable. Default: 1. > >> +- maxim,fan1-label- String: Hwmon fan1_label. > >> +- maxim,fan2-label- String: Hwmon fan2_label. > > > > Perhaps 2 fan sub nodes. reg for fan number, status for enabled, and > > label for label. > > OK. > > Right now a fan’s number of pulses and the PWM frequency are configured using > the hwmon sysfs interface (which defines standard controls for those), but as > those are characteristics of the hardware, should they also be configured via > the device tree binding? > > >> +- maxim,pwm-zero-fan-can-fail - 0: Fan failure detection disabled > >> when PWM is > >> + ramping to 0%. > >> +1: Fan failure detection enabled for all PWM > >> + values. > >> +Default: 0. > > > > All these can be boolean… > > OK. The only issue I see is when the default is ‘true’ in the device, but > I’ll try to avoid that. Sometimes I wish that you could set a boolean to > false in DTS files. > > > > >> +- maxim,temp1-label - String: Hwmon temp1_label. > >> +- maxim,temp2-label - String: Hwmon temp2_label. > >> +- maxim,temp2-ideality- Set ideality factor for the remote > >> temperature > >> +sensor. Integer with range 0 to 63, > >> +representing a multiplication factor of 0.9844 > >> +to 1.0489. Default: 24 (1.0080). > > > > No maxim,temp1-ideality? > No - the device only lets you set the ideality of the ‘external' temperature > sensor. I guess if there is an ideality for the internal temperature sensor, > it would be hard-wired as a characteristic of the part that was used. > > > Not sure what to do with these, but perhaps > > also as sub-nodes. Surely we have some bindings already for devices with > > multiple temp sensors. Don't invent something custom here. > > I’ll look into it. > > What is the best way to distinguish between ‘fan’ and ‘temp’ sub-nodes? Do I > require a ‘compatible’ string? > > Thanks! > > John. > > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Convert USB documentation to ReST format
On Tue, 11 Apr 2017 16:58:40 +0200 Greg Kroah-Hartman wrote: > Nope, they don't apply to my tree, it was probably based on yours. And > the first two are ones I shouldn't be taking. > > So, feel free to take all of these with a: > Acked-by: Greg Kroah-Hartman > for the USB-related patches (2-21). I have now done that. Thanks, Mauro! jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 resend 00/20] ILP32 for ARM64
On Tue, Apr 11, 2017 at 08:42:24PM +0200, Florian Weimer wrote:
> On 04/11/2017 08:36 PM, Yury Norov wrote:
> >>Also, the latest benchmarks I've seen were mostly for user space
> >>while I'm more concerned with the user-kernel interface
> >>(https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2).
> >
> >>On the glibc testing side, have the regressions been identified/fixed?
> >
> >I run LTP for testing the ABI and kernel, and there is no failures in
> >ltplite scenario. With glibc testsuite, there's only 3 failures
> >comparing to lp64. (Steve, fix me if something changed.) This is
> >slides on ilp32 from Linaro Connect, hope you'll find it useful.
> >
> >https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing
>
> The listed failures are:
>
> misc/tst-sync_file_range
> nptl/tst-stack4
> malloc/tst-mallocstate
>
> If necessary, I will fix malloc/tst-mallocstate once there's support for a
> new architecture in build-many-glibcs.py. The failure is
> architecture-independent, it's related to the lack of a compat symbol and
> the difficulty of checking for that at the Makefile or test level.
>
> nptl/tst-stack4 is also a generic failure, I think.
That would be great, thanks.
> misc/tst-sync_file_range is probably a real failure related to argument
> passing. I think this system call was problematic on other architectures,
> too.
At first glance, it's pretty trivial, both on glibc and kernel side:
GLIBC:
int
sync_file_range (int fd, __off64_t offset, __off64_t len, unsigned int flags)
{
#if defined (__NR_sync_file_range2)
return SYSCALL_CANCEL (sync_file_range2, fd, flags, SYSCALL_LL64 (offset),
SYSCALL_LL64 (len));
#elif defined (__NR_sync_file_range)
return SYSCALL_CANCEL (sync_file_range, fd,
__ALIGNMENT_ARG SYSCALL_LL64 (offset),
SYSCALL_LL64 (len), flags);
#endif
}
And kernel:
ENTRY(compat_sys_sync_file_range2_wrapper)
regs_to_64 x2, x2, x3
regs_to_64 x3, x4, x5
b sys_sync_file_range2
ENDPROC(compat_sys_sync_file_range2_wrapper)
Anyway, I'll check everything and report here.
Yury
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs-rst: add input docs at main index and use kernel-figure
On Tue, 11 Apr 2017 07:01:19 -0300 Mauro Carvalho Chehab wrote: > This patch contains the final bits of the input documentation > conversion. The linux-input tree has already the ReST conversion > patches, but it doesn't have the > Documentation/sphinx/load_config.py script with implements > the kernel-figure directive, as it got merged via docs tree. > > So, either one of you should merge from the other tree or this > patch should be sent in separate upstream after both trees > gets merged. What do you prefer? How about if I send it Linusward toward the end of the merge window? FWIW, while I think the conversion is great, I'm not fully pleased with having it as a separate top-level document. Probably what needs to be done here is to split it up into two pieces, one for driver-api and one for userspace-api. But that can happen later, I guess. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] devicetree: Document the max31760 device binding.
v2:
- Fixup based on comments.
Signed-off-by: John Muir
---
.../devicetree/bindings/hwmon/max31760.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt
diff --git a/Documentation/devicetree/bindings/hwmon/max31760.txt
b/Documentation/devicetree/bindings/hwmon/max31760.txt
new file mode 100644
index ..760fdf0b55e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max31760.txt
@@ -0,0 +1,72 @@
+MAX31760 fan controller
+---
+
+This device supports I2C only. Fan sub-nodes must be defined in order to enable
+the fan tachometer input. See also the datasheet:
+https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf
+
+Required node properties:
+ - compatible: "maxim,max31760"
+ - reg: The I2C address of the device. This is 0x50 - 0x57 depending on the
+ hardware configuration.
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+
+Optional node properties:
+ - maxim,fan-fail-full-only: Boolean; Assert a fan failure only when the PWM is
+ at 100%.
+ - maxim,fan-rd-signal: Boolean; Fans provide a rotation detection (RD) signal
+ instead of generating square-wave pulses.
+ - maxim,fan-rd-polarity-high: Boolean; RD is high when the fan is running, not
+ low. Only relevant when fan-rd-signal is true.
+ - maxim,fan-signal-enabled: Boolean; Externally driving FF/FS low should force
+ PWM output to 100%.
+ - maxim,fan-spin-up-enabled: Boolean; For fan startup set the PWM to 100%
until
+ tach is detected or two seconds have passed before reducing to the target
+ value.
+ - maxim,pwm-polarity-negative: Boolean; 100% PWM is when PWM is low, not high.
+ - maxim,pwm-pulse-stretch-enabled: Boolean; Enable PWM pulse stretching.
+ - maxim,pwm-zero-fan-can-fail: Boolean; Enable fan failure detection while
+ ramping to 0% PWM.
+
+Fan sub-nodes must be present in order to enable the fan.
+
+Required fan sub-node properties:
+ - reg: Fan address. Must be <0x00> or <0x01>.
+
+Optional fan sub-node properties:
+ - label: String; Assigned to the hwmon fanX_label property.
+
+Temperature sub-nodes are optional.
+
+Required temp sub-node properties:
+ - reg: Temperature sensor address. Must be <0x00> or <0x01>.
+
+Optional temp sub-node properties:
+ - label: String; Assigned to the hwmon tempX_label property.
+ - ideality: For temperature node with reg 1 only: Set ideality factor for the
+ remote temperature sensor. Integer with range 0 to 63, representing a
+ multiplication factor of 0.9844 to 1.0489. Default: 24 (1.0080).
+
+Example:
+ max31760@50 {
+ compatible = "maxim,max31760";
+ reg = <0x50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ maxim,fan-spin-up-enabled;
+
+ fan@0 {
+ reg = <0x00>;
+ label = "Left";
+ };
+ fan@1 {
+ reg = <0x01>;
+ label = "Right";
+ };
+ temp@1 {
+ reg = <0x01>;
+ label = "CPU";
+ };
+ };
--
2.12.2.715.g7642488e1d-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] hwmon: Add MAX31760 fan controller driver.
Add a driver for the Maxim Integrated MAX31760 Precision Fan Speed Controller. v2: - Fixup open firmware code. - Add a few comments. Signed-off-by: John Muir --- Documentation/hwmon/max31760 | 41 ++ drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/max31760.c | 1461 ++ 4 files changed, 1513 insertions(+) create mode 100644 Documentation/hwmon/max31760 create mode 100644 drivers/hwmon/max31760.c diff --git a/Documentation/hwmon/max31760 b/Documentation/hwmon/max31760 new file mode 100644 index ..6f53ac6112a5 --- /dev/null +++ b/Documentation/hwmon/max31760 @@ -0,0 +1,41 @@ +Kernel driver max31760 +== + +Supported chips: + * Maxim Integrated MAX31760 +Prefix: 'max31760' +Addresses scanned: none +Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf + +Author: + John Muir + +Description +--- + +The MAX31760 integrates temperature sensing along with precision PWM fan +control. Please read the datasheet referenced above for a comprehensive +description of this device. + +This device driver's hwmon integration provides the common sysfs interfaces to +manage two fans and two temperature sensors, and pwm controls for the fan speed. +A temperature to pwm lookup table is exposed via a series of 'auto_point' +configuration files. See Documentation/hwmon/sysfs-interface for more +information. + +The following custom controls are defined (in the custom sub-directory): + +control- Accepts control commands: + "reset" - Execute a soft reset of the device. + "clearff" - Clear the fan fault. + +eeprom_read- Read from the EEPROM into registers. +eeprom_write- Write register contents to the EEPROM. + Write "0" to these to read or write the entire register + contents. Write a bit-field as per the datasheet to write a + portion of the register contents. + +pwm1_fan_fault - PWM value in the range of 0 to 255 used when a fan is faulty. + +pwm1_ramp_rate - PWM increment per second when the PWM value is changed. + Accepted values are 8, 16, 32, or 255 (instantaneous). diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 337e9078df0a..83c9b46a3876 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -895,6 +895,16 @@ config SENSORS_MAX6697 This driver can also be built as a module. If so, the module will be called max6697. +config SENSORS_MAX31760 + tristate "Maxim MAX31760 fan controller" + depends on I2C + help + If you say yes here you get support for the Maxim Integrated + MAX31760 Precision Fan-Speed Controller. + + This driver can also be built as a module. If so, the module + will be called max31760. + config SENSORS_MAX31790 tristate "Maxim MAX31790 sensor chip" depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index d2bdccc000e6..e0ab73e0caa6 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o obj-$(CONFIG_SENSORS_MAX6642) += max6642.o obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MAX6697) += max6697.o +obj-$(CONFIG_SENSORS_MAX31760) += max31760.o obj-$(CONFIG_SENSORS_MAX31790) += max31790.o obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o diff --git a/drivers/hwmon/max31760.c b/drivers/hwmon/max31760.c new file mode 100644 index ..f3de3526d802 --- /dev/null +++ b/drivers/hwmon/max31760.c @@ -0,0 +1,1461 @@ +/* Maxim Integrated MAX31760 Precision Fan-Speed Controller driver + * + * Copyright (C) 2017 Google, Inc. + * Author: muirj + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME "max31760" + +/* + * MAX31760 registers. + * Indentation helps identify how these constants apply: + * Register number. + * Per-register bit fields. + * Values for multi-bit fields. + */ +#define MAX31760_REG_CR1 0x00 /* Control Register 1 */ +#define MAX31760_CR1_TIS0x01 /* Temperature Index Source */ +#define MAX31760_CR1_MTI0x02 /* Maximum Temperature Index */ +#define MAX31760_CR1_PPS0x04 /* PWM Polarity *
[PATCH v2 0/2] Add Maxim Integrated MAX31760 fan controller driver.
Add a device driver for the MAX31760 I2C device with a hwmon interface and a few open firmware device properties. v2: - Fixup device tree binding documentation. - max32760: Fix OF code and add some comments. John Muir (2): hwmon: Add MAX31760 fan controller driver. devicetree: Document the max31760 device binding. .../devicetree/bindings/hwmon/max31760.txt | 72 + Documentation/hwmon/max31760 | 41 + drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/max31760.c | 1461 5 files changed, 1585 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt create mode 100644 Documentation/hwmon/max31760 create mode 100644 drivers/hwmon/max31760.c -- 2.12.2.715.g7642488e1d-goog -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] init: add support to directly boot to a mapped device
Hi Will,
[auto build test ERROR on dm/for-next]
[also build test ERROR on v4.11-rc6 next-20170411]
[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/Enric-Balletbo-i-Serra/dm-boot-a-mapped-device-without-an-initramfs/20170412-071136
base:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
for-next
config: x86_64-randconfig-x010-201715 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the
linux-review/Enric-Balletbo-i-Serra/dm-boot-a-mapped-device-without-an-initramfs/20170412-071136
HEAD 76c4f3dfe69e92fc617c7d30e966931aec694c75 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
init/do_mounts_dm.c: In function 'dm_parse_targets':
>> init/do_mounts_dm.c:231:32: error: passing argument 3 of 'kstrtoull' from
>> incompatible pointer type [-Werror=incompatible-pointer-types]
if (kstrtoull(opt.start, 10, &(*target)->begin))
^
In file included from include/linux/list.h:8:0,
from include/linux/async.h:16,
from init/do_mounts_dm.c:8:
include/linux/kernel.h:282:18: note: expected 'long long unsigned int *' but
argument is of type 'sector_t * {aka long unsigned int *}'
int __must_check kstrtoull(const char *s, unsigned int base, unsigned long
long *res);
^
init/do_mounts_dm.c:240:32: error: passing argument 3 of 'kstrtoull' from
incompatible pointer type [-Werror=incompatible-pointer-types]
if (kstrtoull(opt.start, 10, &(*target)->length))
^
In file included from include/linux/list.h:8:0,
from include/linux/async.h:16,
from init/do_mounts_dm.c:8:
include/linux/kernel.h:282:18: note: expected 'long long unsigned int *' but
argument is of type 'sector_t * {aka long unsigned int *}'
int __must_check kstrtoull(const char *s, unsigned int base, unsigned long
long *res);
^
cc1: some warnings being treated as errors
vim +/kstrtoull +231 init/do_mounts_dm.c
225 if (!get_dm_option(&opt, DM_FIELD_SEP)) {
226 DMERR("failed to parse starting sector"
227" for target %s<%ld>", dev->name, i);
228 goto parse_fail;
229 }
230
> 231 if (kstrtoull(opt.start, 10, &(*target)->begin))
232 goto parse_fail;
233
234 if (!get_dm_option(&opt, DM_FIELD_SEP)) {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [GIT PULL] PCI: Support for configurable PCI endpoint
Hi Bjorn, On Wednesday 12 April 2017 01:04 AM, Bjorn Helgaas wrote: > On Mon, Apr 10, 2017 at 10:43:28AM -0500, Bjorn Helgaas wrote: >> On Wed, Apr 05, 2017 at 02:22:20PM +0530, Kishon Vijay Abraham I wrote: >>> Hi Bjorn, >>> >>> Please find the pull request for PCI endpoint support below. I've >>> also included all the history here. >> >> Thanks, I applied these (with v7 of the first patch) to pci/host-designware >> for v4.12. > > Ok, sorry, I screwed this up. I think my branch actually had v5, not > v6. But I *think* I fixed it. Here's the diff from my branch to your > git tree. Apparently you haven't pushed the v7 patch there, so I > *think* the diff below is the diff between v6 and v7 of that first > patch. I just checked your pci/host-designware branch and it looks correct. Thanks for sorting this out. Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH tip/master 2/3] kprobes: Allocate kretprobe instance if its free list is empty
* Masami Hiramatsu wrote: > On Thu, 30 Mar 2017 08:53:32 +0200 > Ingo Molnar wrote: > > > > > * Masami Hiramatsu wrote: > > > > > > So this is something I missed while the original code was merged, but > > > > the concept > > > > looks a bit weird: why do we do any "allocation" while a handler is > > > > executing? > > > > > > > > That's fundamentally fragile. What's the maximum number of parallel > > > > 'kretprobe_instance' required per kretprobe - one per CPU? > > > > > > It depends on the place where we put the probe. If the probed function > > > will be > > > blocked (yield to other tasks), then we need a same number of threads on > > > the system which can invoke the function. So, ultimately, it is same > > > as function_graph tracer, we need it for each thread. > > > > So then put it into task_struct (assuming there's no > > kretprobe-inside-kretprobe > > nesting allowed). > > No, that is possible to put several kretprobes on same thread, e.g. > the func1() is called from func2(), user can put kretprobes for each > function at same time. > So the possible solution is to allocate new return-stack for each task_struct, > and that is what the function-graph tracer did. > > Anyway, I'm considering to integrate kretprobe_instance with the ret_stack. > It will increase memory usage for kretprobes, but can provide safer way > to allocate kretprobe_instance. Ok, that sounds good to me. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
