From: Nicholas Piggin
> Sent: 10 February 2017 18:23
> After bc3551257a ("powerpc/64: Allow for relocation-on interrupts from
> guest to host"), a getppid() system call goes from 307 cycles to 358
> cycles (+17%). This is due significantly to the scratch SPR used by the
> hypercall.
>
> It turns o
From: Arnd Bergmann
> Sent: 08 February 2017 21:15
>
> When CONFIG_KASAN is in use, the sed_ioctl function uses unusually large
> stack,
> as each possible ioctl argument gets its own stack area plus redzone:
Why not do a single copy_from_user() at the top of sed_ioctl() based on
the _IOC_DIR() a
From: Michal Suchánek
> Sent: 02 February 2017 11:30
...
> The word is marked correctly as __be64 in that patch because count and
> handle are swapped to BE when saved to it and the whole word is then
> swapped again when loaded. If you just load ((u64)IBMVTPM_VALID_CMD <<
> 56 | ((u64)VTPM_TPM_COM
From: Tyrel Datwyler
> Sent: 27 January 2017 18:03
> On 01/26/2017 05:50 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2017-01-26 at 17:42 -0800, Tyrel Datwyler wrote:
> >> On 01/26/2017 12:22 PM, Michal Suchnek wrote:
> >>> Hello,
> >>>
> >>> building ibmvtpm I noticed gcc warning complaining that
From: Michal Suchánek
> building ibmvtpm I noticed gcc warning complaining that second word of
> struct ibmvtpm_crq in tpm_ibmvtpm_suspend is uninitialized.
>
> The structure is defined as
>
> struct ibmvtpm_crq {
> u8 valid;
> u8 msg;
> __be16 len;
> __be32 data;
From: Anton Blanchard
> Sent: 25 January 2017 23:01
> gcc trunk has failed to build PowerPC64 kernels for a month or so. The issue
> is in oprofile, which is common code but ends up being sucked into
> arch/powerpc and therefore subject to the -Werror applied to arch/powerpc:
...
> linux/arch/power
From: Michael Ellerman
> Sent: 24 January 2017 06:16
> Anton Blanchard writes:
> >> We added:
> >>
> >> BUILD_BUG_ON(!__builtin_constant_p(feature))
> >>
> >> to cpu_has_feature() and mmu_has_feature() in order to catch usage
> >> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately
From: 'Naveen N. Rao'
> Sent: 23 January 2017 19:22
> On 2017/01/15 09:00AM, Benjamin Herrenschmidt wrote:
> > On Fri, 2017-01-13 at 23:22 +0530, 'Naveen N. Rao' wrote:
> > > > That rather depends on whether the processor has a store to load
> > > > forwarder
> > > > that will satisfy the read fro
From: Ard Biesheuvel
> Sent: 18 January 2017 13:53
..
> It turns out that this odd treatment of absolute symbols (i.e.,
> symbols having section number SHN_ABS) is a known issue in GNU ld
>
> https://sourceware.org/ml/binutils/2012-05/msg00019.html
...
Jeepers - that is truly f*cked.
I've even
From: Anton Blanchard
> Sent: 15 January 2017 21:36
> I was debugging a hang on a ppc64le kernel built with clang, and it
> looks to be undefined behaviour with pointer wrapping in the llist code.
>
> A test case is below. llist_for_each_entry() does container_of() on a
> NULL pointer, which wraps
From: Naveen N. Rao
> Sent: 13 January 2017 17:10
> Generate instructions to perform the endian conversion using registers,
> rather than generating two memory accesses.
>
> The "way easier and faster" comment was obviously for the author, not
> the processor.
That rather depends on whether the p
From: Christophe LEROY
> Sent: 13 January 2017 12:15
...
> > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally
> > be true for glibc >= 2.4), and that is all. Mystery solved. Thanks!
> >
>
> Is there a way to know during compilation how the compiler will behave,
> in ord
From: Dmitry Safonov
> Sent: 30 December 2016 15:57
> All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or
> TASK_SIZE_MAX since:
> commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for
> FSBASE/GSBASE upper limits"),
> commit a06db751c321 ("pagemap: check permissions and capabil
From: Harisangam, Sharvari (S.)
> Sent: 28 December 2016 11:07
> Corrected the condition to check if ssi is configured for AC97
> mode. Other modes like dsp_a also satisfy the ANDing condition.
Under the assumption that the constants have 1 bit set nothing is wrong.
David
...
> - r
From: Bjorn Helgaas
> Sent: 29 November 2016 04:15
> If we update a VF BAR while it's enabled, there are two potential problems:
>
> 1) Any driver that's using the VF has a cached BAR value that is stale
> after the update, and
>
> 2) We can't update 64-bit BARs atomically, so the interm
From: Andreas Schwab
> Sent: 28 November 2016 20:29
> Use pr_cont where appropriate, and switch to pr_foo throughout.
> Additionally, lower messages in adb_probe_task to debug level.
Doesn't pr_cont() have its own major problem - garbled messages if
there are concurrent writers?
So it is best avoi
From: Lino Sanfilippo
> Sent: 04 November 2016 20:07
...
> In this case it is IMHO rather the declaration + initialization that makes
> "bar" hard to find at one glance, not the use of RXT. You could do something
> like
>
> [longish list of reverse xmas tree identifiers...]
> struct f
From: Pan Xinhui
> Sent: 20 October 2016 22:28
> Commit ("x86, kvm: support vcpu preempted check") add one field "__u8
> preempted" into struct kvm_steal_time. This field tells if one vcpu is
> running or not.
>
> It is zero if 1) some old KVM deos not support this filed. 2) the vcpu is
> preempte
From: Balbir Singh
> Sent: 19 October 2016 15:00
...
> Here is an example
>
> - *slot = retbuf[0];
> + *slot = retvals.v[0];
>
> Could we hide retvals.v[0] under a macro like
>
> *slot = hcalls_ret_val(retvals, 0);
Ugg..
> Since we could end up with similar issues if
> someone derefere
From: Michael Ellerman [mailto:m...@ellerman.id.au]
> > In the past I've caused orphan sections to error by assigning them
> > to the same address as something that exists.
> > Works with all linkers, even if the error message isn't as useful.
>
> How do you assign them an address without knowing
From: Michael Ellerman
> Sent: 14 October 2016 01:46
...
> > +LDFLAGS_vmlinux:= $(LDFLAGS_vmlinux-y) --orphan-handling=error
>
> At least some old(er) toolchains don't support that:
>
> /opt/cross/kisskb/gcc-4.6.3-nolibc/powerpc-linux/bin/powerpc-linux-ld:
> unrecognized option '--
> orpha
From: Madalin Bucur
> Sent: 04 October 2016 08:33
> Subject: [net-next 08/13] fsl/fman: check pcsphy pointer before use
..
> --- a/drivers/net/ethernet/freescale/fman/fman_memac.c
> +++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
> @@ -507,6 +507,9 @@ static void setup_sgmii_internal_phy(str
From: Nicholas Piggin
> Sent: 16 September 2016 12:59
> On Fri, 16 Sep 2016 11:43:13 +0000
> David Laight wrote:
>
> > From: Nicholas Piggin
> > > Sent: 16 September 2016 10:53
> > > On Thu, 15 Sep 2016 18:31:54 +0530
> > > Madhavan Srinivasan wrote
From: Nicholas Piggin
> Sent: 16 September 2016 10:53
> On Thu, 15 Sep 2016 18:31:54 +0530
> Madhavan Srinivasan wrote:
>
> > Force use of soft_enabled_set() wrapper to update paca-soft_enabled
> > wherever possisble. Also add a new wrapper function,
> > soft_enabled_set_return(),
> > added to f
From: Nicholas Piggin
> Sent: 16 September 2016 12:52
> On Fri, 16 Sep 2016 11:30:58 +0000
> David Laight wrote:
>
> > From: Nicholas Piggin
> > > Sent: 16 September 2016 09:58
> > > Implementing busy wait loops with cpu_relax() in callers poses
From: Nicholas Piggin
> Sent: 16 September 2016 09:58
> Implementing busy wait loops with cpu_relax() in callers poses
> some difficulties for powerpc.
>
> First, we want to put our SMT thread into a low priority mode for the
> duration of the loop, but then return to normal priority after exiting
From: Linuxppc-dev
[mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On
Behalf Of
> > > So given what you have above, you'd use something like:
> > >
> > > struct ima_kexec_hdr {
> > > u16 version;
> > > u16 _reserved0;
> > > u32 _reserved1;
> > > u64 buffer_size;
> >
From: Thiago Jung Bauermann
> Sent: 09 August 2016 14:19
...
> > > > +/* Some details preceding the binary serialized measurement list */
> > > > +struct ima_kexec_hdr {
> > > > + unsigned short version;
> > > > + unsigned long buffer_size;
> > > > + unsigned long count;
> > > > +
From: Arnd Bergmann
> Sent: 08 August 2016 16:13
>
> On Monday, August 8, 2016 2:49:11 PM CEST David Laight wrote:
> >
> > > If qe_muram_alloc will return any error, Then IS_ERR_VALUE will always
> > > return 0. it'll not call ucc_fast_free for any failure.
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
Behalf Of Arvind Yadav
> IS_ERR_VALUE() assumes that parameter is an unsigned long.
> It can not be used to check if 'unsigned int' is passed insted.
> Which tends to reflect an error.
> In 64bit architectures sizeof (int)
From: Arvind Yadav
> Sent: 04 August 2016 17:53
> IS_ERR_VALUE() assumes that parameter is an unsigned long.
> It can not be used to check if 'unsigned int' is passed insted.
> Which tends to reflect an error.
> In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
> IS_ERR_VALUE(x) is ((
From: Philippe Bergheaud
> Sent: 04 August 2016 14:56
> This patch fixes a regression introduced by commit b810253.
> It substitutes the type __u8 to u8 in the uapi header cxl.h,
> because the latter is not always defined in userland build
> environments, in particular when cross-compiling libcxl o
From: Arvind Yadav
> Sent: 23 July 2016 19:06
> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> It can not be used to check if an 'unsigned int' reflects an error.
> As they pass an 'unsigned int' into a function that takes an
> 'unsigned long' argument. This happens to work becaus
From: Josh Poimboeuf
> Sent: 22 July 2016 18:46
..
> > >> +/*
> > >> + * Checks if a given pointer and length is contained by the current
> > >> + * stack frame (if possible).
> > >> + *
> > >> + * 0: not at all on the stack
> > >> + * 1: fully within a valid stack frame
> > >> + * 2: fully o
From: Nicholas Piggin
> Sent: 21 July 2016 07:44
...
> @@ -739,7 +739,8 @@ kvmppc_skip_Hinterrupt:
> * Ensure that any handlers that get invoked from the exception prologs
> * above are below the first 64KB (0x1) of the kernel image because
> * the prologs assemble the addresses of these
From: Kees Cook
> Sent: 20 July 2016 16:32
...
> Yup: that's exactly what it's doing: walking up the stack. :)
Remind me to make sure all our customers run kernels with it disabled.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.
From: Paulo Flabiano Smorigo
> Sent: 19 July 2016 14:36
> Ignore assembly files generated by the perl script.
...
> diff --git a/drivers/crypto/vmx/.gitignore b/drivers/crypto/vmx/.gitignore
> new file mode 100644
> index 000..af4a7ce
> --- /dev/null
> +++ b/drivers/crypto/vmx/.gitignore
> @@
From: Dave Young
> On 07/15/16 at 02:19pm, Mark Rutland wrote:
> > On Fri, Jul 15, 2016 at 09:09:55AM -0400, Vivek Goyal wrote:
> > > On Tue, Jul 12, 2016 at 10:42:01AM +0900, AKASHI Takahiro wrote:
> > >
> > > [..]
> > > > -SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
> > > > +
From: Kees Cook
> Sent: 15 July 2016 22:44
> This is a start of the mainline port of PAX_USERCOPY[1].
...
> - if address range is in the current process stack, it must be within the
> current stack frame (if such checking is possible) or at least entirely
> within the current process's stack.
From: Aneesh Kumar K.V
> Sent: 13 July 2016 10:35
>
> This switch few of the page table accessor to use the __raw variant
> and does the cpu to big endian conversion of constants. This helps in
> generating better code.
It might be better to say that checks for a value being 0 don't depend
on the
From: Paulo Flabiano Smorigo
> Sent: 11 July 2016 20:08
>
> This patch add XTS subroutines using VMX-crypto driver.
>
> It gives a boost of 20 times using XTS.
>
> These code has been adopted from OpenSSL project in collaboration
> with the original author (Andy Polyakov ).
Yep, typical openssl
From: Arvind Yadav
> Sent: 07 July 2016 19:38
> -Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
> assigned in ucc_fast_tx_virtual_fifo_base_offset and
> ucc_fast_rx_virtual_fifo_base_offset. These variable are 'unsigned int'.
> So before assginment need a proper type casting
From: Ravi Bangoria
> Sent: 28 June 2016 12:37
>
> Powerpc has long list of branch instructions and hardcoding them in table
> appears to be error-prone. So, add new function to find instruction
> instead of creating table.
>
> Signed-off-by: Naveen N. Rao
> Signed-off-by: Ravi Bangoria
> ---
>
From: Arnd Bergmann
> Sent: 24 June 2016 20:43
> On Friday, June 24, 2016 9:31:35 PM CEST Shreyas B Prabhu wrote:
> > > If those functions are called less often than cpuidle_enter_state(),
> > > we could just move the division there. Since the divisor is constant,
> > > do_div() can convert it into
From: Shreyas B. Prabhu
> Sent: 24 June 2016 09:24
>
> Snooze is a poll idle state in powernv and pseries platforms. Snooze
> has a timeout so that if a cpu stays in snooze for more than target
> residency of the next available idle state, then it would exit thereby
> giving chance to the cpuidle g
From: Jiri Kosina
> Sent: 23 May 2016 19:45
> > 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
Not sure that does what I want.
It appears to allow some 'kill' actions to wake the proc
From: Jiri Kosina
> Sent: 18 May 2016 21:23
> On Wed, 18 May 2016, Josh Poimboeuf wrote:
>
> > Yeah, I think this situation -- a task sleeping on an affected function
> > in uninterruptible state for a long period of time -- would be
> > exceedingly rare and not something we need to worry about fo
From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: 13 May 2016 06:33
...
> Simply denying direct writes to the vector table or preventing mapping
> of the vector table into the user address space does not provide any
> tangible form of protection. Many devices make use of window reg
From: Tian, Kevin
> Sent: 05 May 2016 10:37
...
> > Acutually, we are not aimed at accessing MSI-X table from
> > guest. So I think it's safe to passthrough MSI-X table if we
> > can make sure guest kernel would not touch MSI-X table in
> > normal code path such as para-virtualized guest kernel on
From: Andy Lutomirski
> Sent: 02 May 2016 19:13
...
> I hope your plans include rewriting the current stack unwinder
> completely. The thing in print_context_stack is (a)
> hard-to-understand and hard-to-modify crap and (b) is called in a loop
> from another file using totally ridiculous conventio
From: Chris Smart
> Sent: 28 April 2016 00:52
...
> >In that case what actually completes the copy?
> >I think you'd need to be inside a 'restartable atomic sequence'
> >in which case the cp_abort need only be done when the/a RAS
> >block is detected.
> >
> >Or have I missed something??
>
> It's u
From: Chris Smart
> Sent: 26 April 2016 01:29
> The copy paste facility introduced in POWER9 provides an optimised
> mechanism for a userspace application to copy a cacheline. This is
> provided by a pair of instructions, copy and paste, while a third,
> cp_abort (copy paste abort), provides a clea
From: Andy Shevchenko
> Sent: 21 April 2016 19:15
> ata_sff_qc_issue() can't handle DMA commands and thus we have to avoid it for
> them. Do call ata_bmdma_qc_issue() instead for this case.
>
> Suggested-by: Christian Lamparter
> Signed-off-by: Andy Shevchenko
> ---
> drivers/ata/sata_dwc_460ex
From: Yongji Xie
> Sent: 18 April 2016 11:59
> We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
> which indicates all devices on the bus are protected by the
> hardware which supports IRQ remapping(intel naming).
>
> This flag will be used to know whether it's safe to expose
> MSI-X table
From: Zhiqiang Hou
> Sent: 07 April 2016 04:17
...
> > Is there a reason specific to 85xx to have a different default than every
> > other
> > platform except lpc18xx? The description of MTD_SPI_NOR_USE_4K_SECTORS
> > acknowledges that erase speed is a tradeoff. Why is that concern more
> > comp
From: Kees Cook
> Sent: 04 February 2016 21:01
> Some callers of strtobool were passing a pointer to unterminated strings.
> In preparation of adding multi-character processing to kstrtobool, update
> the callers to not pass single-character pointers, and switch to using the
> new kstrtobool_from_u
From: Yongji Xie
> Sent: 15 January 2016 07:06
>
> MSI-X tables are not allowed to be mmapped in vfio-pci
> driver in case that user get to touch this directly.
> This will cause some performance issues when when PCI
> adapters have critical registers in the same page as
> the MSI-X table.
...
If t
From: Vaibhav Jain
> Sent: 14 January 2016 07:51
> David Laight writes:
>
> > I don't even claim to understand the linux model for handling process
> > address maps, nor what the cxl driver is doing, but the above looks
> > more than dodgy.
> >
> >
From: Michael Ellerman
> Sent: 11 January 2016 09:14
> On Tue, 2015-24-11 at 10:56:18 UTC, Vaibhav Jain wrote:
> > Presently when a user-space process issues CXL_IOCTL_START_WORK ioctl we
> > store the pid of the current task_struct and use it to get pointer to
> > the mm_struct of the process, whi
From: Michael Ellerman
> Sent: 08 January 2016 02:17
> > I doubt you plan to fix all those. So making -Werror configurable seems like
> > the only way forward, then. (Glad you agreed!)
>
> Yep, I'm happy to make Werror configurable.
>
> cxl can probably just use the existing PPC_WERROR.
Personal
From: Alex Williamson
> Sent: 17 December 2015 21:07
...
> > Is this all related to the statements in the PCI(e) spec that the
> > MSI-X table and Pending bit array should in their own BARs?
> > (ISTR it even suggests a BAR each.)
> >
> > Since the MSI-X table exists in device memory/registers ther
> The MSI-X table is paravirtualized on vfio in general and interrupt
> remapping theoretically protects against errant interrupts, so why is
> this PPC64 specific? We have the same safeguards on x86 if we want to
> decide they're sufficient. Offhand, the only way I can think that a
> device can to
From: Russell King - ARM Linux
> Sent: 04 December 2015 17:13
...
> I have a slightly different view...
>
> > > I don't see bust_spinlocks() dealing with any of these locks, so IMHO
> > > trying to make this work in NMI context strikes me as making the
> > > existing solution more unreliable on AR
From: yalin wang
> Sent: 30 November 2015 16:42
> > On Nov 27, 2015, at 19:09, Petr Mladek wrote:
> >
> > Testing has shown that the backtrace sometimes does not fit
> > into the 4kB temporary buffer that is used in NMI context.
> >
> > The warnings are gone when I double the temporary buffer size
From: Cyril Bur
> Sent: 18 November 2015 03:27
...
> The goal of these patches is to rework how the 'math' registers (FP, VEC
> and VSX) are context switched. Currently the kernel adopts a lazy approach,
> always switching userspace tasks with all three facilities disabled and
> loads in each set o
From: Michael Ellerman
> Sent: 10 November 2015 05:09
> __rmem_check_for_overlap() is called very early in boot, and on some
> powerpc systems it's not safe to call WARN that early in boot.
>
> If the overlap check fails the system will oops instead of printing a
> warning. Furthermore because it'
From: Paul E. McKenney
> Sent: 21 October 2015 00:35
...
> There is also the question of whether the barrier forces ordering
> of unrelated stores, everything initially zero and all accesses
> READ_ONCE() or WRITE_ONCE():
>
> P0 P1 P2 P3
> X = 1;
From: Benjamin Herrenschmidt
> Sent: 09 October 2015 09:15
> On Fri, 2015-10-09 at 10:46 +0800, Wei Yang wrote:
> > On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
> > a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
> > from 64bit prefetchable win
From: Scott Wood
> Sent: 24 September 2015 21:14
> > Isn't this a more general problem?
> >
> > If there are multiple remap requests for the same physical page
> > shouldn't the kernel be just increasing a reference count somewhere
> > and returning address in the same virtual page?
> > This should
From: Christophe Leroy
> Sent: 22 September 2015 17:51
...
> Traditionaly, each driver manages one computer board which has its
> own components with its own memory maps.
> But on embedded chips like the MPC8xx, the SOC has all registers
> located in the same IO area.
>
> When looking at ioremaps
From: Brian King
> Sent: 18 September 2015 22:35
...
> > + for (i = 0; i < CXLFLASH_NUM_VLUNS; i++, buf += 22)
>
> Rather than this bug prone hard coded 22, how about never incrementing buf
> and do something
> similar to this:
>
> > + bytes += scnprintf(buf, PAGE_SIZE, "%03d: %016ll
From: Linuxppc-dev Matthew R. Ochs
> Sent: 16 September 2015 22:28
> Interrupt processing can run in parallel to a remove operation. This
> can lead to a condition where the interrupt handler is processing with
> memory that has been freed.
>
> To avoid processing an interrupt while memory may be
From: Segher Boessenkool
> Sent: 17 September 2015 04:19
> On Thu, Sep 17, 2015 at 12:50:12PM +1000, Michael Ellerman wrote:
> > On Wed, 2015-09-16 at 21:54 -0400, Steven Rostedt wrote:
> > > This could be a symptom and not the problem. What the above shows is
> > > that ftrace tried to convert the
From: Colin Ian King
> Sent: 14 September 2015 20:35
> On the unlikely event that drv is null, the current code will
> perform a null pointer dereference with it when printing a dev_dbg
> message. Instead, the BUG_ON check on drv should be performed
> before we emit the dev_dbg message.
...
> diff
> > What about run-time patching memcpy() after the caches are initialised?
>
> Yeah, that's the solution we use on 64-bit.
>
> It also means you can have cpu specific optimisations, which can be patched in
> or out using the cpu feature patching.
I've noticed x86 doing that.
For newer Intel par
From: Christophe Leroy
> Sent: 07 September 2015 15:25
...
> diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
> index 2ef50c6..05b3096 100644
> --- a/arch/powerpc/lib/copy_32.S
> +++ b/arch/powerpc/lib/copy_32.S
> @@ -172,7 +172,16 @@ _GLOBAL(memcpy)
> mtctr r0
> b
From: Michal Sojka
> >> I think GCC uses memcpy() in well known situations like initialising
> >> structures or copying structures.
> >> Shouldn't we just avoid this kind of actions in the very few early init
> >> functions ?
> > Which are the "very few" early init functions? Can you make a list, f
From: Cyril Bur
> Sent: 11 August 2015 07:01
...
> You have a dilema with the use of ugly if (rc = foo()). I don't like it but
> the
> file is littered with it.
>
> Looks like the majority of uses in this file the conditional block is only
> one line then it makes sense (or at least in terms of n
From: Laurent Dufour
> Sent: 31 July 2015 10:30
> This patch fixes several endianness issues detected when running the HVSI
> driver in little endian mode.
>
> These issues are raised in little endian mode because the data exchanged in
> memory between the kernel and the hypervisor has to be in bi
From: Robert Baldyga
> Sent: 31 July 2015 15:00
> Introduce struct usb_ep_caps which contains information about capabilities
> of usb endpoints - supported transfer types and directions. This structure
> should be filled by UDC driver for each of its endpoints, and will be
> used in epautoconf in n
From: Scott Wood
> Sent: 26 May 2015 20:43
...
> > I was thinking of all 64bit targets, not 32bit ones.
>
> Oh, you mean move it out of arch/powerpc? Sounds reasonable, but
> someone should probably check what the resulting code looks like on
> other common arches. OTOH, if we're going to modify
From: Scott Wood ...
> > I'd also have thought that the 64bit C version above would be generally
> > 'good'.
>
> It doesn't generate the addc/addze sequence. At least with GCC 4.8.2,
> it does something like:
>
> mr tmp0, csum
> li tmp1, 0
> li tmp2, 0
> a
From: Linuxppc-dev Christophe Leroy
> Sent: 19 May 2015 16:19
...
> diff --git a/arch/powerpc/include/asm/checksum.h
> b/arch/powerpc/include/asm/checksum.h
> index 5e43d2d..e8d9ef4 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -130,6 +130,22 @
From: Christophe Leroy
> Sent: 19 May 2015 11:08
>
> This patchset implements use of cacheable versions of memset and
> memcpy since when the destination is not cacheable, memset_io
> and memcpy_toio are used.
This isn't the right list to ask, but:
Can someone fix the x86 versions of memset/memcp
From: Thomas Gleixner
> Sent: 22 April 2015 09:45
> On Tue, 21 Apr 2015, Thomas Gleixner wrote:
> > On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> > > I know there are concerns about this, in particular because C11 and
> > > POSIX both require tv_nsec to be 'long', unlike timeval->tv_usec,
> > > which
From: Christophe Leroy
> Sent: 20 April 2015 06:27
> Having a macro will help keep clear code.
...
> * We have to use the MD_xxx registers for the tablewalk because the
> * equivalent MI_xxx registers only perform the attribute functions.
> */
> +
> +#ifdef CONFIG_8xx_CPU15
> +#define DO_8xx_
From: Christophe Leroy
> Linux CodyingStyle recommends to use short variables for local
> variables. ptr is just good enough for those 3 lines functions.
> It helps keep single lines shorter than 80 characters.
...
> -static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t
> dma_add
From: Sowmini Varadhan
> Investigation of multithreaded iperf experiments on an ethernet
> interface show the iommu->lock as the hottest lock identified by
> lockstat, with something of the order of 21M contentions out of
> 27M acquisitions, and an average wait time of 26 us for the lock.
> This i
From: Stephen Rothwell
> This runs a bit faster and removes another use of perl from
> the kernel build.
...
> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
> new file mode 100755
> index ..182eae9cc40d
> --- /dev/null
> +++ b/arch/powerpc/relocs_check.sh
> @@
From: Markus Stockhausen
> [PATCH v1 1/3] SHA1 for PPC/SPE - assembler
>
> This is the assembler code for SHA1 implementation with
> the SIMD SPE instruction set. With the enhanced instruction
> set we can operate on 2 32 bit words in parallel. That helps
> reducing the time to calculate W16-W79.
From: Ingo Molnar
...
> So why not trylock and time out here after a few seconds,
> instead of indefinitely supressing some potentially vital
> output due to some other CPU crashing/locking with the lock
> held?
I've used that for status requests that usually lock a table
to get a consistent view.
From: Markus Stockhausen
> 4K AES tables for big endian
I can't help feeling that you could give more information about how the
values are generated.
...
> + * These big endian AES encryption/decryption tables are designed to be
> simply
> + * accessed by a combination of rlwimi/lwz instruction
From: David Gibson
> arch/powerpc/include/asm/swab.h includes some powerpc specific
> byteswapping functions, which are implemented in terms of powerpc's
> built in byte reversed load/store instructions. There are two problems with
> this:
>
> 1) They're not necessary - gcc is perfectly capable
From: leroy
> Le 20/01/2015 12:09, David Laight a écrit :
> > From Christophe Leroy
> >> Having a macro will help keep clear code.
> > It might remove an #if but it doesn't really help.
> > All it means is that anyone reading the code has to hunt for
&
From Christophe Leroy
> Having a macro will help keep clear code.
It might remove an #if but it doesn't really help.
All it means is that anyone reading the code has to hunt for
the definition before proceeding.
Some comment about what (and why) the extra code is needed
might help.
...
> +
> +#i
From: Joakim Tjernlund
> On Mon, 2015-01-12 at 11:55 +1100, Anton Blanchard wrote:
> > Hi David,
> >
> > > The unrolled loop (deleted) looks excessive.
> > > On a modern cpu with multiple execution units you can usually
> > > manage to get the loop overhead to execute in parallel to the
> > > actu
From: Anton Blanchard
> I noticed ksm spending quite a lot of time in memcmp on a large
> KVM box. The current memcmp loop is very unoptimised - byte at a
> time compares with no loop unrolling. We can do much much better.
>
> Optimise the loop in a few ways:
>
> - Unroll the byte at a time loop
From: leroy christophe
> Le 06/01/2015 13:08, David Laight a écrit :
> >> On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
> >>> All accessed to PGD entries are done via 0(r11).
> >>> By using lower part of swapper_pg_dir as load index to r11
> On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
> > All accessed to PGD entries are done via 0(r11).
> > By using lower part of swapper_pg_dir as load index to r11, we can remove
> > the
> > ori instruction.
> >
> > Signed-off-by: Christophe Leroy
>
> Nice :)
> Acked-by: Joakim Tjer
From: Rusty Russell
> David Laight writes:
> > From: Madhavan Srinivasan [mailto:ma...@linux.vnet.ibm.com]
> > ...
> >> >>> I also wonder if it is possible to inspect the interrupted
> >> >>> code to determine the start/end of the RAS block.
>
301 - 400 of 593 matches
Mail list logo