Hello Medve
On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1 wrote:
>
> You're correct. MV64360 seems to be stale. Do you want to re-spin your
> patch to get rid of it?
No problem, bu should I respin in from the current official git
or on top of yours?
>
> (I wouldn't create a
Since PPC_MUTIPLATFORM was removed, it was impossible to select the
driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity
to remove the stale MV64360 config option.
Signed-off-by: Gabriel Paubert
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 214a92d..aff4f8c
On Sun, Jun 14, 2009 at 04:04:36PM +0300, Avi Kivity wrote:
> Paul Mackerras wrote:
>> Avi Kivity writes:
>>
>>
>>> An alternative implementation using 64-bit cmpxchg will recover most
>>> of the costs of hashed spinlocks. I assume most serious 32-bit
>>> architectures have them?
>>>
>>
On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
> Brad Boyer writes:
>
> > On Fri, Jul 03, 2009 at 12:14:41PM +0530, kernel mailz wrote:
> >> b. using m or Z with a memory address. I tried replacing m/Z but no change
> >> Is there some guideline ?
> >> gcc documentation says Z is
On Tue, Jul 07, 2009 at 02:40:02PM +0200, Andreas Schwab wrote:
> Gabriel Paubert writes:
>
> > On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
> >> The 'Z' constraint is required for a memory operand for insns that don't
> >> have a
On Tue, Jul 21, 2009 at 12:31:36PM +0200, David Jander wrote:
> On Tuesday 21 July 2009 11:52:51 you wrote:
> > On Tue, Jul 21, 2009 at 11:16:52AM +0200, David Jander wrote:
> > > For bigger systems we often run a debian-derived OS like Ubuntu, and many
> > > pieces are compiled natively on the tar
On Tue, Sep 03, 2019 at 01:31:57PM -0500, Segher Boessenkool wrote:
> On Tue, Sep 03, 2019 at 07:05:19PM +0200, Christophe Leroy wrote:
> > Le 03/09/2019 à 18:04, Segher Boessenkool a écrit :
> > >(Why are they separate though? It could just be one loop var).
> >
> > Yes it could just be a single
On Thu, Sep 05, 2019 at 11:09:35AM +0200, Andreas Schwab wrote:
> On Sep 05 2019, Aleksa Sarai wrote:
>
> > diff --git a/lib/struct_user.c b/lib/struct_user.c
> > new file mode 100644
> > index ..7301ab1bbe98
> > --- /dev/null
> > +++ b/lib/struct_user.c
> > @@ -0,0 +1,182 @@
> > +//
On Sat, Sep 30, 2023 at 09:50:41AM -0500, Steve French wrote:
> On Fri, Sep 29, 2023 at 3:06 AM David Howells via samba-technical
> wrote:
> >
> >
> > Jeff Layton wrote:
> >
> > > Correct. We'd lose some fidelity in currently stored timestamps, but as
> > > Linus and Ted pointed out, anything bel
On Sat, Nov 18, 2023 at 05:45:03PM -0600, Timothy Pearson wrote:
> During floating point and vector save to thread data fr0/vs0 are clobbered
> by the FPSCR/VSCR store routine. This leads to userspace register corruption
> and application data corruption / crash under the following rare condition:
On Mon, Aug 22, 2022 at 05:33:35PM +0200, Pali Rohár wrote:
> On Monday 22 August 2022 14:25:57 Christophe Leroy wrote:
> > Le 19/08/2022 à 23:12, Pali Rohár a écrit :
> > > Currently powerpc early debugging contains lot of platform specific
> > > options, but does not support standard UART / seria
On Thu, Sep 01, 2022 at 05:22:32AM +, Christophe Leroy wrote:
>
>
> Le 01/09/2022 à 00:45, Segher Boessenkool a écrit :
> > Hi!
> >
> > On Tue, Aug 30, 2022 at 09:10:02AM +, Christophe Leroy wrote:
> >> Le 30/08/2022 à 11:01, Nicholas Piggin a écrit :
> >>> On Tue Aug 30, 2022 at 3:24 PM
On Sat, Nov 07, 2020 at 01:23:28PM +1000, Nicholas Piggin wrote:
> ISA v2.06 (POWER7 and up) as well as e6500 support lbarx and lwarx.
Hmm, lwarx exists since original Power AFAIR, s/lwarx/lharx/ perhaps?
Same for the title of the patch and the CONFIG variable.
Gabriel
> Add a c
On Sat, Nov 07, 2020 at 05:42:57AM -0600, Segher Boessenkool wrote:
> On Sat, Nov 07, 2020 at 08:12:13AM +0100, Gabriel Paubert wrote:
> > On Sat, Nov 07, 2020 at 01:23:28PM +1000, Nicholas Piggin wrote:
> > > ISA v2.06 (POWER7 and up) as well as e6500 support lbarx and lwarx.
&
On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > - couple of fixes and preparatory patches
> >
> > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > [un]registering I
On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote:
> On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> >
On Tue, Feb 12, 2008 at 01:30:03PM +0100, Gabriel Paubert wrote:
> On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote:
> > On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > On Fri, 2008-02-08 at 01:44 +0100, Bart
On Fri, Oct 19, 2007 at 10:14:54AM +1000, Paul Mackerras wrote:
> Sergei Shtylyov writes:
>
> > > What problem do you see arising from this?
> >
> > Timers firing too early.
>
> Only if the minimum interrupt latency is less than 1 decrementer
> tick. That seems pretty unlikely to me unless
On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> Hi guys,
>
> Since this is a generic PPC coding question I figured I'd send it here.
> We're
> looking to make the small effort to get ZFS-FUSE working on PPC and there is
> a need (as is implemented on Solaris) for some 'atomic' math
On Tue, Sep 04, 2007 at 01:31:07PM +0100, Matt Sealey wrote:
>
> Gabriel Paubert wrote:
> >On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> >>Hi guys,
> >>
> >>The Solaris PPC code drop included most of these functions for 32-bit ops
> &g
On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> This changes PowerPC to use the generic time infrastructure for
> gettimeofday et al. We register a clocksource which uses the timebase
> register, or the RTC on the 601.
>
> It also gets rid of the RTC update stuff. IIRC we discu
On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > > This changes PowerPC to use the generic time infrastructure for
> > &
On Fri, Sep 07, 2007 at 04:20:12AM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > > This changes PowerPC to use the generic time infrastructure for
> > > gettimeofday et al. We registe
On Thu, Sep 06, 2007 at 12:24:15PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 07:05:47PM +0200, Gabriel Paubert wrote:
> > On Thu, Sep 06, 2007 at 12:01:23PM -0500, Scott Wood wrote:
> > > On Thu, Sep 06, 2007 at 06:55:35PM +0200, Gabriel Paubert wrote:
> > > &g
On Sun, Sep 09, 2007 at 07:55:35PM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > The solution now used by i386/x86-64/sparc64 is
> > CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
> > to use something similar, but the generic code has some
On Tue, Sep 11, 2007 at 05:49:17PM +1000, Tony Breeds wrote:
> With these functions implemented we cooperate better with the generic
> timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Looks fine, there is still the problem that most PPC RTC
seem to prefer update on the s
On Wed, Jun 25, 2008 at 10:34:32AM -0500, Scott Wood wrote:
> Kumar Gala wrote:
> >>+/* Macros to workout the correct index for the FPR in the thread
> >>struct */
> >>+#define FPRNUMBER(i) (((i) - PT_FPR0) >> 1)
> >>+#define FPRHALF(i) (((i) - PT_FPR0) % 2)
> >
> >Have you looked at what the comp
On Wed, Jun 25, 2008 at 11:17:45AM -0500, Scott Wood wrote:
> Gabriel Paubert wrote:
> >On Wed, Jun 25, 2008 at 10:34:32AM -0500, Scott Wood wrote:
> >>Kumar Gala wrote:
> >>>>+/* Macros to workout the correct index for the FPR in the thread
> >>&g
On Fri, Feb 29, 2008 at 12:48:33AM -0500, Jarod Wilson wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-02-28 at 13:42 -0500, Jarod Wilson wrote:
> >> On Thursday 28 February 2008 01:25:59 am Benjamin Herrenschmidt wrote:
> Under Mac OS X, system.log says "FireWire (OHCI) Apple ID 31 bu
On Fri, Feb 29, 2008 at 10:56:45PM -0500, Steven Rostedt wrote:
>
> On Sat, 1 Mar 2008, Benjamin Herrenschmidt wrote:
> >
> > Do we have any indication that it performs better than the C one ?
>
> See below.
>
> >
> > Ben.
> >
>
> > >
> > > +_GLOBAL(strncmp)
> > > + mtctr r5
> > > + addir
On Mon, Mar 03, 2008 at 03:35:01PM +0100, Stefan Richter wrote:
> Gabriel Paubert wrote:
> > I have a Pismo which I use on a virtually
> > daily basis (and about to remove the last remnants of MacOS on it).
> > However I have disabled Firewire because it would not sleep and
On Thu, Mar 06, 2008 at 12:26:00AM +0100, Stefan Richter wrote:
> Gabriel Paubert wrote:
> >>>I have a Pismo which I use on a virtually
> >>>daily basis (and about to remove the last remnants of MacOS on it).
> >>>However I have disabled Firewire becau
On Thu, Apr 03, 2008 at 09:09:04AM -0400, mejjad lahcen wrote:
> hi all of you ,
> I am wndering if someone has already done test for interrupt latency on
> linx 2.6.23 mpc5200b.
> I am working on writing a driver which is get SPi involved on design, and I
> know that the spi interrupt will occur
On Sun, Apr 20, 2008 at 10:27:27PM +1000, Paul Mackerras wrote:
> Marvin writes:
>
> > will this be the end of life for all the PReP's ? I remember a patch posted
> > some month ago, but didn't heard anything since then. Any news? Or just let
> > it die quietly?
>
> No, I'm still planning on ge
On Mon, Apr 21, 2008 at 03:07:13PM +0200, Alexander van Heukelum wrote:
> On Mon, 21 Apr 2008 22:13:06 +1000, "Paul Mackerras" <[EMAIL PROTECTED]>
> said:
> > Alexander van Heukelum writes:
> > > Powerpc would pick up an optimized version via this chain: generic fls64
> > > ->
> > > powerpc __fls -
On Mon, Apr 21, 2008 at 02:57:47PM -0500, Kumar Gala wrote:
> 603 CPUs have the same issue that some 750 CPUs have in that they can crash
> in funny ways if a store from an FPU register instruction is executed on a
> register that has never been initialized since power on. This patch fixes
> it by
On Thu, Apr 24, 2008 at 11:27:37AM +0200, Johannes Berg wrote:
> On Thu, 2008-04-24 at 02:24 -0700, David Miller wrote:
> > From: Johannes Berg <[EMAIL PROTECTED]>
> > Date: Thu, 24 Apr 2008 11:21:52 +0200
> >
> > > Hmm. Why is that whole cpu_clock stuff in place anyway? powerpc has
> > > perfectl
On Sat, May 03, 2008 at 12:55:10AM -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Sat, 03 May 2008 17:50:17 +1000
>
> > Best would be if we could get those runtime bits linked in the module
> > itself, but I don't know enough about our toolchain to know if th
On Thu, May 01, 2008 at 08:22:08AM -0500, Kumar Gala wrote:
> >>So we have 4 actual exceptions:
> >>* CriticalInput (some external device signaled this. There are two
> >>concepts of critical. One is error the other is high priority)
> >>However this would have the same caveats as any ExternalInp
On Mon, May 05, 2008 at 10:55:38PM +0400, Anton Vorontsov wrote:
> Sometimes (particularly on MPC8610HPCD) we want IRQ-less CMOS RTC for
> the boards without (or disabled) i8259 PICs.
>
> We lookup the device tree for "chrp,iic" compatible devices, and if not
> found we do not assign RTC IRQ.
I s
Hi,
I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
The last message I have is:
gunzip (0x <- some more hex digits)
The configuration has been created from a working 2.6.25 one with
make oldconfig and answering N to new config options.
Anybody has seen
On Tue, Jul 15, 2008 at 08:05:49PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote:
> > Hi,
> >
> > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> > The last message I have is:
> > gu
On Tue, Jul 15, 2008 at 04:27:49PM +0100, Matt Sealey wrote:
> If you built this kernel yourself, you need to do it from a system with
> an up-to-date binutils (2.18) otherwise, it does this.
>
Thanks, this is likely the problem. The distribution is Debian stable
with all security udates but the
On Wed, Jul 16, 2008 at 08:38:14PM -0400, Jon Smirl wrote:
> On 7/16/08, Milton Miller <[EMAIL PROTECTED]> wrote:
> > Hi.
>
> Previous threads have mentioned that binutil-2.17 is broken for
> building powerpc kernels. It is fixed in binutils-2.18.
>
> I have encountered this and upgrading to 2.18
On Sat, Jul 26, 2008 at 10:36:42PM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2008-07-26 at 12:02 +0100, Hugh Dickins wrote:
> >
> > Hmm, perhaps it is doing sibling calls differently even without the
> > explicit -fno-optimize-sibling-calls (but when I add that option,
> > the vmlinux size do
On Tue, Sep 23, 2008 at 07:55:01PM +0530, Srinivasa Ds wrote:
> On Tuesday 23 September 2008 17:00:01 Ingo Molnar wrote:
>
> > > applied to [the new topic] tip/core/signal, thanks Srinivasa! There
> > > are some other pending x86 signal changes already, so i based
> > > tip/core/signal on tip/x86/
[Marked off-topic because it is exclusively hardware related]
On Mon, Oct 13, 2008 at 08:12:02AM -0500, Bill Gatliff wrote:
> Laurent Pinchart wrote:
>
> >
> > There are no internal pull-up or pull-down resistors on the MPC8248 GPIO
> > pins. I know our hardware engineer has a valid point theo
On Thu, Oct 23, 2008 at 03:44:21PM +0200, Johannes Berg wrote:
> Hi,
>
> Andreas (Cc'ed) asked whether it was possible to use snd-aoa on his
> machine, a PowerMac3,6. It appears that it is fairly easy since the
> machine seems to use a regular i2sbus.
>
> To identify it, after looking through my
On Thu, Oct 23, 2008 at 05:41:02PM +0200, Johannes Berg wrote:
> On Thu, 2008-10-23 at 17:35 +0200, Gabriel Paubert wrote:
>
> > On my almost 8 years old PowerMac (PowerMac3,4 accorfing to OF):
> >
> > $ find /proc/device-tree/ -wholename '*sound/device-id' |
On Fri, Oct 24, 2008 at 10:40:23AM +0200, Johannes Berg wrote:
> On Thu, 2008-10-23 at 18:43 +0200, Gabriel Paubert wrote:
>
> > > Can you tell me which devices it has, like does it have line-in,
> > > microphone, headphones, ...?
> >
> > I'm not an
On Tue, Nov 11, 2008 at 02:10:39PM +, David Woodhouse wrote:
> On Mon, 2008-11-10 at 16:40 +0100, Alessandro Zummo wrote:
> > Adds in-kernel hctosys functionality that can
> > be used by ntp sync code.
> >
> > This is an RFC and has not been tested, I just want
> > to check if something simila
On Tue, Nov 11, 2008 at 12:58:59PM -0800, David Brownell wrote:
> On Tuesday 11 November 2008, David Woodhouse wrote:
> > I believe you were also concerned that some device wouldn't want the
> > behaviour given by the existing sync_cmos_clock() function and workqueue
> > stuff in kernel/ntp.c, wher
On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> Joakim Tjernlund writes:
>
> > This little hack changes the kernel sys call handling in an crude
> > way and then it works. Apperently the kernel thinks is an error if the
> > syscall returns a value between -_LAST_ERRNO and -1.
>
On Fri, Nov 21, 2008 at 08:03:06PM +1100, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > On Fri, Nov 21, 2008 at 10:52:14AM +1100, Paul Mackerras wrote:
> > > Joakim Tjernlund writes:
> > >
> > > > This little hack changes the kernel sys call ha
On Wed, Nov 26, 2008 at 05:09:39PM +0100, Norbert van Bolhuis wrote:
>
> ok, so it depends on the decrementer frequency
> (which is 4166 on my system).
>
> Btw. the main oscillator on my board is not 83.3 mhz,
> it's 66 mhz as well.
66MHz is the crystal frequency, but then clock generators
use
On Mon, Jan 19, 2009 at 10:33:40AM +0100, Wolfgang Grandegger wrote:
> Hello,
>
> I want to provoke a "floating point exception" by doing a division by 0.
> The expection does come as expected on my x86 PC:
>
> $ ./divby0
> Floating point exception
>
> but not on my MPC5200 board. Any idea w
> > 00:00:00:00:00:00. And the old 2.6.26 code doesn't compile so the
> > workaround is dead.
>
> This is probably because mv643xx_eth now no longer fails registration
> of the interface if no valid PHY could be found. Gabriel Paubert
> (CC'ed) had a pa
On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > Here is an implementation to allow PReP systems to boot under the
> > arch/powerpc codebase, one of the few remaining platforms supported in
> > arch/ppc but not so far in arch/powerpc.
>
> > Too big for the list, the patch is
On Mon, Jul 02, 2007 at 01:51:42PM +0200, Segher Boessenkool wrote:
> >>+ external-control;
> >>
> >>Really?
> >
> >Well, is anybody actually using eciwx/ecowx?
>
> That's not the point -- the device tree should only
> say "external-control" if the CPU actually supports
> it; AFA
On Thu, Jul 05, 2007 at 12:03:00PM -0500, Olof Johansson wrote:
> Workaround for errata 4290: The decrementer ticks at half the expected rate
> so load it with half the value it would otherwise be loaded with.
>
>
> Index: 2.6.21/include/asm-powerpc/time.h
> ==
On Fri, May 18, 2007 at 05:52:45PM +0100, Matt Sealey wrote:
> Kumar Gala wrote:
> >
> > On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
> >>>
> >>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
> >>> easily.
>
On Thu, Feb 11, 2021 at 06:34:43AM +, Christophe Leroy wrote:
> unrecoverable_exception() is never expected to return, most callers
> have an infiniteloop in case it returns.
>
> Ensure it really never returns by terminating it with a BUG(), and
> declare it __no_return.
>
> It always GCC to
On Wed, Feb 23, 2022 at 06:11:36PM +0100, Christophe Leroy wrote:
> Commit a82adfd5c7cb ("hardening: Introduce CONFIG_ZERO_CALL_USED_REGS")
> added zeroing of used registers at function exit.
>
> At the time being, PPC64 clears volatile registers on syscall exit but
> PPC32 doesn't do it for perfo
On Wed, Feb 23, 2022 at 05:27:39PM -0600, Segher Boessenkool wrote:
> On Wed, Feb 23, 2022 at 09:48:09PM +0100, Gabriel Paubert wrote:
> > On Wed, Feb 23, 2022 at 06:11:36PM +0100, Christophe Leroy wrote:
> > > + /* Zero volatile regs that may contain sensitive kernel data */
&g
On Wed, Mar 23, 2022 at 11:18:40AM +1100, Alexey Kardashevskiy wrote:
>
>
> On 3/22/22 13:12, Michael Ellerman wrote:
> > Alexey Kardashevskiy writes:
> > > So far the RELACOUNT tag from the ELF header was containing the exact
> > > number of R_PPC_RELATIVE/R_PPC64_RELATIVE relocations. However
On Wed, Apr 06, 2022 at 02:01:48PM +1000, Alexey Kardashevskiy wrote:
> So far the RELACOUNT tag from the ELF header was containing the exact
> number of R_PPC_RELATIVE/R_PPC64_RELATIVE relocations. However the LLVM's
> recent change [1] make it equal-or-less than the actual number which
> makes it
Hi,
On Thu, Apr 22, 2021 at 02:13:34PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Apr 16, 2021 at 05:44:52PM +1000, Daniel Axtens wrote:
> > Sathvika Vasireddy writes:
> > Ok, if I've understood correctly...
> >
> > > + ra = ra & ~0x3;
> >
> > This masks off t
On Thu, Apr 22, 2021 at 06:26:16PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Apr 23, 2021 at 12:16:18AM +0200, Gabriel Paubert wrote:
> > On Thu, Apr 22, 2021 at 02:13:34PM -0500, Segher Boessenkool wrote:
> > > On Fri, Apr 16, 2021 at 05:44:52PM +1
On Tue, May 18, 2021 at 08:43:39PM +0200, Christophe Leroy wrote:
>
>
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
> > Do not allow inserting breakpoints on the suffix of a prefix instruction
> > in kprobes.
> >
> > Signed-off-by: Jordan Niethe
> > ---
> > v8: Add this back from v3
> > ---
On Fri, Jul 24, 2020 at 07:25:25PM +1000, Michael Ellerman wrote:
> We have powerpc specific logic in our page fault handling to decide if
> an access to an unmapped address below the stack pointer should expand
> the stack VMA.
>
> The code was originally added in 2004 "ported from 2.4". The roug
On Sun, Aug 23, 2020 at 12:54:33AM +0800, Guohua Zhong wrote:
> >In generic version in lib/math/div64.c, there is no checking of 'base'
> >either.
> >Do we really want to add this check in the powerpc version only ?
>
> >The only user of __div64_32() is do_div() in
> >include/asm-generic/div64.h
On Tue, Aug 25, 2020 at 09:45:07PM +1000, Jordan Niethe wrote:
> Update the CPU to ISA Version Mapping document to include Power10 and
> ISA v3.1.
>
> Signed-off-by: Jordan Niethe
> ---
> Documentation/powerpc/isa-versions.rst | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documen
On Thu, Aug 27, 2020 at 12:39:06PM +0200, Christophe Leroy wrote:
> Hi,
>
> Le 27/08/2020 à 10:28, Giuseppe Sacco a écrit :
> > Il giorno gio, 27/08/2020 alle 09.46 +0200, Giuseppe Sacco ha scritto:
> > > Il giorno gio, 27/08/2020 alle 00.28 +0200, Giuseppe Sacco ha scritto:
> > > > Hello Christop
On Mon, Feb 01, 2021 at 09:55:44AM -0600, Christopher M. Riedl wrote:
> On Thu Jan 28, 2021 at 4:38 AM CST, David Laight wrote:
> > From: Christopher M. Riedl
> > > Sent: 28 January 2021 04:04
> > >
> > > Reuse the "safe" implementation from signal.c except for calling
> > > unsafe_copy_from_user(
On Mon, Jul 26, 2021 at 05:42:43PM +0200, Michal Suchanek wrote:
> commit 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in
> raise_backtrace_ipi()")
> introduces udelay() call without including the linux/delay.h header.
> This may happen to work on master but the header that decla
On Thu, Jul 13, 2017 at 01:25:46PM +1000, Matt Brown wrote:
> This adds emulation for the bpermd instruction.
>
> Signed-off-by: Matt Brown
> ---
> arch/powerpc/lib/sstep.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/
On Tue, Nov 14, 2017 at 02:32:17PM +, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in pr_err error message text. Also
> fix spelling mistake in proceeding comment.
s/proceeding/preceding/ ?
>
> Signed-off-by: Colin Ian King
> ---
> drivers/crypto/nx/nx-842
On Mon, Dec 18, 2017 at 03:15:51PM -0800, Ram Pai wrote:
> On Mon, Dec 18, 2017 at 02:28:14PM -0800, Dave Hansen wrote:
> > On 12/18/2017 02:18 PM, Ram Pai wrote:
> > > b) minimum number of keys available to the application.
> > > if libraries consumes a few, they could provide a library
> > >
On Tue, Feb 21, 2017 at 09:24:38AM +1300, Hamish Martin wrote:
> This patch series adds the ability to configure the THREAD_SHIFT value and
> thereby alter the stack size on powerpc systems. We are particularly
> interested
> in configuring for a 32k stack on PPC64.
>
> Using an NXP T2081 (e6500
On Sun, Mar 05, 2017 at 06:37:37AM -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2017 at 09:26:47PM +1100, Michael Ellerman wrote:
> > > I see a panic in early boot when building with a recent gcc toolchain.
> > > The issue is a divide by zero, which is undefined. Older toolchains
> > > let us
On Sun, Mar 05, 2017 at 11:24:56AM -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote:
> > > > Erk sorry. One of the static checkers spotted it, but I hadn't got
> > > > around to fixing it because it seemed to not act
On Thu, Dec 21, 2017 at 12:52:01AM +1000, Nicholas Piggin wrote:
> Shifted left by 16 bits, so the low 16 bits of r14 remain available.
> This allows per-cpu pointers to be dereferenced with a single extra
> shift whereas previously it was a load and add.
> ---
> arch/powerpc/include/asm/paca.h
On Mon, Jan 29, 2018 at 01:33:08PM -0600, Larry Finger wrote:
> In kernel 4.15, the modprobe step on my PowerBook G5 started complaining that
PowerBook G5? Really, could you send a pic! :-)
> there was no module license for ans-lcd.
>
> Signed-off-by: Larry Finger
> ---
> drivers/macintosh
, and I'm not sure that
I fully understand it.
Nevertheless the following patch fixes the regression, but there might
be a better way to solve the problem.
If you pick up this trivial patch as is, you may add:
Signed-off-by: Gabriel Paubert
diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kc
On Wed, Jan 31, 2018 at 10:03:46AM +, James Hogan wrote:
> On Wed, Jan 31, 2018 at 10:37:30AM +0100, Gabriel Paubert wrote:
> > Hi,
> >
> > yesterday I recompiled the kernel on my late 2005 G4 PowerBook, and the
> > Wifi stopped working. After comparing the
On Thu, Mar 22, 2018 at 04:24:24PM +1100, Oliver wrote:
> On Thu, Mar 22, 2018 at 1:35 AM, David Laight wrote:
> >> x86 has compiler barrier inside the relaxed() API so that code does not
> >> get reordered. ARM64 architecturally guarantees device writes to be
> >> observed
> >> in order.
> >
> >
On Thu, Mar 22, 2018 at 08:25:43PM +1100, Oliver wrote:
> On Thu, Mar 22, 2018 at 7:20 PM, Gabriel Paubert wrote:
> > On Thu, Mar 22, 2018 at 04:24:24PM +1100, Oliver wrote:
> >> On Thu, Mar 22, 2018 at 1:35 AM, David Laight
> >> wrote:
> >> >> x86 has
On Tue, Mar 27, 2018 at 11:01:44PM +1100, Michael Ellerman wrote:
> This commit adds security feature flags to reflect the settings we
> receive from firmware regarding Spectre/Meltdown mitigations.
>
> The feature names reflect the names we are given by firmware on bare
> metal machines. See the
On Wed, May 16, 2018 at 02:48:29PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> I have decided that any email sent to the linuxppc-dev mailing list
> that contains an HTML attachment (or is just an HTML email) will be
> rejected. The vast majority of such mail are spam (and I have to spend
> time
Hi,
On Mon, Nov 14, 2016 at 11:34:52PM +0530, Madhavan Srinivasan wrote:
> Local atomic operations are fast and highly reentrant per CPU counters.
> Used for percpu variable updates. Local atomic operations only guarantee
> variable modification atomicity wrt the CPU which owns the data an
On Fri, May 13, 2016 at 04:16:57PM +1000, Michael Ellerman wrote:
> On Thu, 2016-12-05 at 15:32:22 UTC, Christophe Leroy wrote:
> > With the ffs() function as defined in arch/powerpc/include/asm/bitops.h
> > GCC will not optimise the code in case of constant parameter, as shown
> > by the small exe
On Mon, May 23, 2016 at 10:46:02AM +0200, Christophe Leroy wrote:
> current_stack_pointeur() is a single instruction function. it
> It is not worth breaking the execution flow with a bl/blr for a
> single instruction
Are you sure that the result is always the same?
Calling an external function p
On Mon, May 23, 2016 at 10:46:36AM +0200, Christophe Leroy wrote:
> lmw/stmw have a 1 cycle (2 cycles for lmw on some ppc) in addition
> and implies serialising, however it reduces the amount of instructions
> hence the amount of instruction fetch compared to the equivalent
> operation with several
On Sun, May 29, 2016 at 10:03:50PM +1000, Anton Blanchard wrote:
> From: Anton Blanchard
>
> In both __giveup_fpu() and __giveup_altivec() we make two modifications
> to tsk->thread.regs->msr. gcc decides to do a read/modify/write of
> each change, so we end up with a load hit store:
>
>
On Wed, Aug 10, 2016 at 01:17:55AM -0700, Christian Kujau wrote:
> On Wed, 10 Aug 2016, Benjamin Herrenschmidt wrote:
> > We cannot do those initializations from apply_feature_fixups() as
> > this function runs in a very restricted environment in 32-bit where
> > the kernel isn't running at its lin
On Fri, Aug 05, 2016 at 01:28:02PM +0200, Christophe Leroy wrote:
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/kernel/misc_32.S | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
> index e025230..e180
On Wed, Aug 10, 2016 at 12:18:15PM +0200, Christophe Leroy wrote:
>
>
> Le 10/08/2016 à 10:56, Gabriel Paubert a écrit :
> >On Fri, Aug 05, 2016 at 01:28:02PM +0200, Christophe Leroy wrote:
> >>Signed-off-by: Christophe Leroy
> >>---
> >> arch/po
On Thu, Aug 11, 2016 at 05:11:19PM -0500, Segher Boessenkool wrote:
> On Thu, Aug 11, 2016 at 11:34:37PM +0200, Gabriel Paubert wrote:
> > On the other hand gcc did at the time a very poor job (quite an
> > understatement) at bswapdi when compiling for 64 bit processors
>
On Thu, Aug 18, 2016 at 11:44:20AM +0200, Christophe Leroy wrote:
> SPRN_ICR must be read for clearing the internal freeze signal which
> is asserted by the single step exception, otherwise the timebase and
> decrementer remain freezed
Minor nit: s/freezed/frozen/
If the timebase and decrementer
On Thu, Aug 18, 2016 at 12:13:21PM +0200, Christophe Leroy wrote:
>
>
> Le 18/08/2016 à 11:58, Gabriel Paubert a écrit :
> >On Thu, Aug 18, 2016 at 11:44:20AM +0200, Christophe Leroy wrote:
> >>SPRN_ICR must be read for clearing the internal freeze signal which
> >&
101 - 200 of 204 matches
Mail list logo
