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
return 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
=' cmdline option
> powerpc/speculation: Support '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
s discussed previously -- I really like this new
global option. Feel free to add
Reviewed-by: Jiri Kosina
for the whole set.
Thanks,
--
Jiri Kosina
SUSE Labs
tly prefer if
it goes via your tree.
Thanks,
--
Jiri Kosina
SUSE Labs
hael, are you fine with this going through LP tree, or do you plan to
take it through yours?
Thanks,
--
Jiri Kosina
SUSE Labs
o send me
> > 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/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
ible to also
> signal/wake the idle tasks?
Scheduler 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
m mount(/dev) seems 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
ainers. Namely, I'd 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
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
TASK_KILLABLE tasks (e.g. waiting on NFS 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 Kosi
ded semantic value for "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
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&#x
k'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
s).
But 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
_
>
> 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
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;
>
; implementation 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
on x86_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 guaran
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
you 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
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.
--
Jiri Kosina
SUSE Labs
_
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
nto livepatching.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
for-4.7/arch-independent-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
ur side.
Alternatively, you can 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
ndency (rest 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
so broken that it's guaranteed
that noone would ever produce a patch that brings the kernel down" is
okay, but I really don't feel that just documenting the limitation is
sufficient and safe in this case; kudos to Torsten here for
iden
x27; is a global 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
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
VE for >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
e
it'll miss the upcoming merge window 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 current
- I apply the 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
>
int of the whole thing).
Therefore it must not consider 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
strates 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
__
nter is saved 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
_
lain profiling 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 m
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
_
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 mail
inus 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
ms 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
ons called by ftrace must be marked as notrace, there is no
way out of it.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
dles recursion protection by itself (depending 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
ll is fine.
> I was tired & jet lagged, so I 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 mai
ersonality to PER_LINUX32 or PER_LINUX
> > discards 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.
sonality() 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
---
Resned of patch sent on Thu, 2 Aug 2012 09:10:03 +0200 (CEST)
arch/powerpc/kernel/syscalls.c |8
() 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
---
changed since v1: fix the bit ops to reflect the fact that PER_LINUX is
actually 0
arch/powerpc/kernel/syscalls.
sonality() 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
---
Found accidentally. Untested, I don't have the hardware.
arch/powerpc/kernel/syscalls.c |8
1
it a7ccf3775219 ("char: Fix typo 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
, unsigned int
> > flow_type)
> > if (vold != vnew)
> > mpic_irq_write(src, MPIC_INFO(IRQ_VECTOR_PRI), vnew);
> >
> > - return IRQ_SET_MASK_OK_NOCOPY;;
> > + return IRQ_SET_MASK_OK_NOCOPY;
> > }
> >
> > void mpic_set_vector(un
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
> > &
y chance we can get a fix into linux-next?
>
> 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 not sure how
> to fix that. "depends on HID && POWER_SUPPLY && HID == POWER_SUPPLY"?
How about making it 'default POWER_SUPPLY' instead?
I somehow feel that we'd rather avoid too much 'default y's.
Thanks,
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
d QE3 for UCC5 in Eth mode, QE9
> - * and QE12 for QE MII management singals in PMUXCR
> + * and QE12 for QE MII management signals in PMUXCR
> * register.
>*/
Applied.
--
Jiri Kosina
SUSE Labs,
f (cpu_has_feature(CPU_FTR_PURR))
This doesn't seem to be present in 37-rc1, 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 ma
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
>
(including complete
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.
___
C) 2008-2009
> * Ben. Herrenschmidt (b...@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
itable recipient for this patch.
Yup, I am usually applying all 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
> >
> > Signed-off-by: Peter Huewe
>
> 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 le
On Tue, 12 May 2009, Sankar P wrote:
> Fixes a trivial spelling error in powerpc code comments.
>
> Signed-off-by: Sankar P
Applied to trivial tree, thanks.
--
Jiri Kosina
SUSE Labs
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.
66 matches
Mail list logo
