the RC4.
Given the lack of input from Ankit, I have just queued the patch below in
for-6.2/upstream-fixes.
From: Jiri Kosina
Subject: [PATCH] HID: revert CHERRY_MOUSE_000C quirk
This partially reverts commit f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL
quirk
for some mice"), as it
ur
original patch?
Unless I hear otherwise, I will just drop
the quirk for USB_DEVICE_ID_CHERRY_MOUSE_000C before this gets clarified.
Thanks,
--
Jiri Kosina
SUSE Labs
n 200 OK and serve the same content:
> > Replace HTTP with HTTPS.
> >
> > Signed-off-by: Alexander A. Klimov
>
> Looks good!
>
> Acked-by: Bastien Nocera
Applied, thanks.
--
Jiri Kosina
SUSE Labs
On Mon, 18 May 2020, Jiri Kosina wrote:
> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > > implicit-declaration compile errors when building Cache-Sram.
> > >
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > > ‘insta
map(cache_sram->base_virt);
> >^~~
> >roundup
> > cc1: all warnings being treated as errors
> >
> > Fixed: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> > Signed-off-by: WANG Wenhu
>
> Reviewed-by: Christophe Leroy
As this doesn't seem to have been picked up for linux-next yet, I am
picking it up now.
Thanks,
--
Jiri Kosina
SUSE Labs
mitigations=' cmdline option
> s390/speculation: Support 'mitigations=' cmdline option
> arm64/speculation: Support 'mitigations=' cmdline option
Tested-by: Jiri Kosina (on x86)
Reviewed-by: Jiri Kosina
Thanks,
--
Jiri Kosina
SUSE Labs
I really like this new
global option. Feel free to add
Reviewed-by: Jiri Kosina
for the whole set.
Thanks,
--
Jiri Kosina
SUSE Labs
es via your tree.
Thanks,
--
Jiri Kosina
SUSE Labs
are you fine with this going through LP tree, or do you plan to
take it through yours?
Thanks,
--
Jiri Kosina
SUSE Labs
> them.
>
> I didn't send this. It's an ancient (8 years old) email... I have no
> idea how it got resent while I was asleep...
I got a few mails from 2010 this morning as well. From the headers it
looks like Mauro (CCed) re-bounced them for some reason.
--
Jiri Kosina
SUSE Labs
+--
> kernel/livepatch/core.c | 30 +
> kernel/livepatch/transition.c| 41
> ++++
> kernel/livepatch/transition.h| 1 +
> kernel/signal.c | 4 ++-
I'd like to be queuing this patchset for the next merge window, so if
there are any objections for the out-of-kernel/livepatch/* changes, please
speak up now.
Thanks.
--
Jiri Kosina
SUSE Labs
uler won't select idle task in case there is *anything* else runnable
in any other sched class anyway. And if that is the case, there is no need
for explicit wakeup, as idle task would get scheduled anyway implicitly.
So idle task is a little bit more difficult than that, unfortunately.
--
Jiri Kosina
SUSE Labs
like the biggest suspect.
These:
> hid: module verification failed: signature and/or required key missing -
> tainting kernel
> hidraw: raw HID events driver (C) Jiri Kosina
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
are for sure unrelated.
Please focus on figuring out why mounting /dev doesn't succeed.
--
Jiri Kosina
SUSE Labs
On Mon, 13 Feb 2017, Josh Poimboeuf wrote:
> Here's v5 of the consistency model
I have ammended the patches with all the received ACKs and applied to
'for-4.12/klp-hybrid-consistency-model' branch of livepatching.git.
Thanks,
--
Jiri Kosina
SUSE Labs
really appreciate Acks for patches
touching sched/idle.c and s390/x86/ppc arch specific bits from the
respective maintainers.
Peter, Ingo, Heiko, Michael, please?
Thanks,
--
Jiri Kosina
SUSE Labs
mod, unsigned long
> - type, unsigned long loc, unsigned long value)
> -{
> - /* This requires infrastructure changes; we need the loadinfos. */
> - return -ENOSYS;
> -}
> -
> static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
> {
> regs->nip = ip;
Applied, thanks.
--
Jiri Kosina
SUSE Labs
I/O, but not limited only to
that; feel free to set it whereever you need) are skipped. Please note
that TASK_KILLABLE is actually a _mask_ that includes TASK_UNINTERRUPTIBLE
as well; therefore the '==' test skips such tasks.
--
Jiri Kosina
SUSE Labs
_
or "those who know", but the others will
(pretty much correctly) consider it to be a stackframe from a function
call, and be done with it.
What am I missing?
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxpp
On Mon, 23 May 2016, David Laight wrote:
> Related, please can we have a flag for the sleep and/or process so that
> an uninterruptible sleep doesn't trigger the 'hung task' detector
TASK_KILLABLE
> and also stops the process counting towards the 'load average'.
TASK_NOLOAD
--
Ji
se task'd be in TASK_UNINTERRUPTIBLE for more than 120s, hung
task detector would trigger anyway.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
t let's face it, this should be pretty uncommon, because (a) it's not
realistic for the wait times to be really indefinite (b) the task is
likely to be in TASK_KILLABLE rather than just plain TASK_UNINTERRUPTIBLE.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev
fe or not.
>
> The problem might be if the task get rescheduled between the check
> for the pending stuff
The code in question is running with preemption disabled.
> or inside the klp_patch_task() function.
We must make sure that this function doesn't go to sleep. It's only used
to clear
On Mon, 2 May 2016, Jiri Kosina wrote:
> > FWIW, I just tried this:
> >
> > static bool is_entry_text(unsigned long addr)
> > {
> > return addr >= (unsigned long)__entry_text_start &&
> > addr < (unsigned long)__entry_text_end;
>
plementation would print out the entire contents of pt_regs so that
> people reading the stack trace will know the registers at the time of
> the exception, which might be helpful.
Sorry for being dense, but how do you distinguish here between a "real"
kernel entry, that pushes pt_
64.
Well, MCEs are more or less x86-specific as well. But otherwise good
point, thanks Andy.
So, how does stack layout generally look like in case when NMI is actually
running on proper kernel stack? I thought it's guaranteed to contain
pt_regs anyway in all cases. Is that not guaranteed to be the
On Wed, 27 Apr 2016, Jiri Kosina wrote:
> I've incorporated most of the feedback (*) and pushed out to
> livepatching.git#for-4.7/livepatching-doc so everybody please send any
> followup documentation patches on top of that branch.
(*) Balbir, some of your comments were a bit too vagu
really
sure about it? 'kretprobes' is plural form in this sentence, so what's the
rationale for your proposed change?
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
igned-off-by: Petr Mladek <pmla...@suse.com>
Good stuff, thanks.
I've incorporated most of the feedback (*) and pushed out to
livepatching.git#for-4.7/livepatching-doc so everybody please send any
followup documentation patches on top of that branch.
-
On Wed, 20 Apr 2016, Balbir Singh wrote:
> Thanks, do we have a summary of what the relocation changes look like?
This work is queued in
livepatching.git#for-4.7/arch-independent-klp-relocations
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mail
tching.git#for-4.7/livepatching-ppc64 and
merged that branch into for-next as well.
That branch already contains all the relocation changes queued for 4.7, so
as much testing of the merged result as possible on ppc64 would be
appreciated.
Thanks everybody,
--
Jir
ndent-klp-relocations might not be completely
trivial.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
an rebase on top of livepatching.git#for-next, and
I'll take it directly.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
st of livepatching bits
for ppc64le) will not go in before 4.7 merge window anyway.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
sufficient and safe in this case; kudos to Torsten here for
idenfitfying the problem before it actually became The Problem
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
l symbol, and hence everybody is
generating 'global call' for it, and that's pretty much it.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
d better be placed into a separate chapter, but I'd really like to
see it included.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
;8args / varargs function.
At that time, only starting to put support in the kernel for that is waaay
to late :)
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ndow anyway).
My primary worry there is what Torsten pointed out, i.e. functions with
either varargs or more than 8 args needing special care.
Also, I'd like to have this positively reviewed by at least one more
livepatching maintainer (I am currently looking into it myself, but my
understand
e ppc livepatching support on top of that
- I send a pull request to Linus only after powerpc#next gets merged to
Linus' tree
Sounds good?
> Also regardless of who takes it an Ack from Steve for the ftrace changes
> would be good.
Absolute
any traceable function to be leaf (even
though it might "look" leaf from the source code); if it does, then the
mprofile-kernel option is useless.
So I actually would dare to call it a bug.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
es my point -- if this one-gcc-option-to-rule-them-all would
exist, it needs to be generic enough to describe these kinds of
constraints (who knows what other restrictions will pop up when exploring
other, more exotic, architectures later).
Thanks,
--
Jiri Kosina
SUSE Labs
___
ved needs to happen before
the fentry/profiling call.
I don't think this will be an issue on ARM64, but it definitely is
something that should be taken into account in case the gcc option is
meant to be really generic.
Thanks,
--
Jiri Kosina
SUSE Labs
call (-pg) or kernel profiling call
(-mprofile-kernel), gcc must always assume that global function (that will
typically have just one instance for the whole address space) will be
called.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Lin
On Wed, 20 Jan 2016, Michael Ellerman wrote:
> For me the series doesn't even boot, even with livepatching disabled.
Could you please post config and dmesg from that non-booting kernel?
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing l
e we sure that gcc is doing the right thing here?
I am far from claiming understanding of ppc64 ABI, but from what Vojtech
told me I understood that saving link register is necessary for (at least)
graph tracer to work properly.
Thanks,
--
Jiri Kosina
SUSE Labs
_
minus the holiday season, and
> no further problems arose. Independently verified by Petr Mladek --
> don't forget his high-level fix.
Hi everybody,
so what are the current plans with this one, please? Is this going through
ppc tree, ftrace tree, or does it have issues that need to be worked on
befo
seems like most (if not all) of the things called
from nmi_{enter,exit}() would be nops there anyway.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
of it.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
on the
per-ftrace-ops FTRACE_OPS_FL_RECURSION_SAFE flag).
It's however not really well-defined what to do when recursion would
happen. Therefore __notrace__ annotation, that just completely avoid such
situation by making tracing impossible, looks like saner general solution
to me.
--
Jiri Kosina
might have just had a brain fail...
Probably just missed that the first patch used PER_LINUX and the second
one PER_MASK, or whatever.
Anyway, thanks.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
any flags stored in the top three bytes
Use personality() macro to compare only PER_MASK bytes and make sure that
we are setting only the bits that should be set, instead of
overwriting the whole value.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
changed since v1: fix the bit
() macro to compare only PER_MASK bytes and make sure that
we are setting only the bits that should be set, instead of overwriting
the whole value.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
Resned of patch sent on Thu, 2 Aug 2012 09:10:03 +0200 (CEST)
arch/powerpc/kernel/syscalls.c |8
to compare only PER_MASK bytes and make sure that
we are setting only the bits that should be set, instead of
overwriting the whole value.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
actually 0
arch/powerpc/kernel
() macro to compare only PER_MASK bytes and make sure that
we are setting only the bits that should be set, instead of
overwriting the whole value.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
Found accidentally. Untested, I don't have the hardware.
arch/powerpc/kernel/syscalls.c |8
1
in viotape.c) from the trivial tree.
Dropped a7ccf3775219 in my tree, thanks for report Stephen.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 12 Dec 2011, Tony Breeds wrote:
On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote:
On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote:
Hm. How about making it depends on HID POWER_SUPPLY? I think that
would needlessly disable it if HID is also modular, but I'm
(IRQ_VECTOR_PRI), vnew);
- return IRQ_SET_MASK_OK_NOCOPY;;
+ return IRQ_SET_MASK_OK_NOCOPY;
}
void mpic_set_vector(unsigned int virq, unsigned int vector)
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
MII management singals in PMUXCR
+ * and QE12 for QE MII management signals in PMUXCR
* register.
*/
Applied.
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
Linuxppc-dev mailing list
, so I am taking it to trivial
queue. If this has been already merged to another tree, let me know.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
drops/rewrites) so we'll likely be getting conflicts there. I will
reroute them to Greg.
- I will fold all the patches into one. We don't need one commit per one
specific typo.
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
Linuxppc-dev mailing list
On Tue, 16 Mar 2010, Rupjyoti Sarmah wrote:
-Original Message-
From: Jiri Kosina [mailto:jkos...@suse.cz]
Sent: Tuesday, March 16, 2010 9:18 PM
To: Rupjyoti Sarmah
Cc: linux-ker...@vger.kernel.org
Subject: Re: Failure with the 2.6.34-rc1 kernel
On Tue, 16 Mar 2010, Rupjyoti
...@kernel.crashing.org), IBM Corp.
Applied to trivial queue, thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
the comment typo fixes, as it makes the
source more grepping-friendly.
Applied, thanks Stefan.
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
peterhu...@gmx.de
Hi Jiri,
this one got merged by Benjamin, so you can drop it from your queue :)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=948c28fe3001f2c9d852dff2a0b2c69fe7cec91b
Dropped, thanks for letting me know.
--
Jiri Kosina
SUSE Labs, Novell Inc
On Tue, 12 May 2009, Sankar P wrote:
Fixes a trivial spelling error in powerpc code comments.
Signed-off-by: Sankar P sankar.curios...@gmail.com
Applied to trivial tree, thanks.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev
66 matches
Mail list logo
