On Wed, Oct 16, 2019 at 11:44:03PM +0200, Greg Kurz wrote:
> On Fri, 27 Sep 2019 13:53:32 +0200
> Greg Kurz wrote:
>
> > This brings some fixes and allows to start more VMs with an in-kernel
> > XIVE or XICS-on-XIVE device.
> >
> > Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs system level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Signed-off-
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are
Little Endian. So add this optional property to help identify
them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.
On 2019/10/10 2:46, Scott Wood wrote:
On Wed, 2019-10-09 at 16:41 +0800, Jason Yan wrote:
Hi Scott,
On 2019/10/9 15:13, Scott Wood wrote:
On Wed, 2019-10-09 at 14:10 +0800, Jason Yan wrote:
Hi Scott,
Would you please take sometime to test this?
Thank you so much.
On 2019/9/24 13:52, Jas
This adds tests which will validate architecture page table helpers and
other accessors in their compliance with expected generic MM semantics.
This will help various architectures in validating changes to existing
page table helpers or addition of new ones.
This test covers basic page table entry
This series adds a test validation for architecture exported page table
helpers. Patch in the series adds basic transformation tests at various
levels of the page table.
This test was originally suggested by Catalin during arm64 THP migration
RFC discussion earlier. Going forward it can include mo
On Okt 20 2019, Thomas Gleixner wrote:
> But for the sake of making a non-sensical specification happy we can add a
> NULL pointer check for this. The interesting question is what should be
> returned in this case.
0 if the clock id is valid, EINVAL otherwise.
Andreas.
--
Andreas Schwab, sch..
On Sun, 20 Oct 2019, Andreas Schwab wrote:
> On Okt 20 2019, Thomas Gleixner wrote:
>
> > POSIX does not mention anything about the validity of the pointer handed to
> > clock_getres().
>
> Sure it does: "If the argument res is not NULL, the resolution of the
> specified clock shall be stored in
On Sun, 2019-10-20 at 12:06 -0400, Mimi Zohar wrote:
> On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote:
> > Asymmetric private keys are used to sign multiple files. The kernel
> > currently support checking against blacklisted keys. However, if the
> > public key is blacklisted, any file signed
On Okt 20 2019, Thomas Gleixner wrote:
> POSIX does not mention anything about the validity of the pointer handed to
> clock_getres().
Sure it does: "If the argument res is not NULL, the resolution of the
specified clock shall be stored in the location pointed to by res. If
res is NULL, the cloc
On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote:
> Asymmetric private keys are used to sign multiple files. The kernel
> currently support checking against blacklisted keys. However, if the
> public key is blacklisted, any file signed by the blacklisted key will
> automatically fail signature v
On Sun, 20 Oct 2019, Andreas Schwab wrote:
> On Okt 20 2019, Thomas Gleixner wrote:
>
> > clock_getres(NULL) is hardly valid.
>
> Of course not, it lacks a parameter.
You know exactly what I mean.
> > So special casing
> >
> > clock_getres(clock, NULL);
> >
> > just to make a test case h
On Sat, 2019-10-19 at 14:06 -0400, Nayna Jain wrote:
> While secure boot permits only properly verified signed kernels to be
> booted, trusted boot takes a measurement of the kernel image prior to
> boot that can be subsequently compared against good known values via
> attestation services.
>
Ins
On Okt 20 2019, Thomas Gleixner wrote:
> clock_getres(NULL) is hardly valid.
Of course not, it lacks a parameter.
> So special casing
>
> clock_getres(clock, NULL);
>
> just to make a test case happy is a pointless exercise which does not make
> any sense at all.
POSIX requires it to work.
On Sun, 20 Oct 2019, Christophe Leroy wrote:
> Adding Thomas to the discussion as the commit is from him.
>
> Le 20/10/2019 à 11:53, Andreas Schwab a écrit :
> > On Okt 20 2019, Christophe Leroy wrote:
> >
> > > Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
> > > > On Okt 19 2019, Christophe L
Adding Thomas to the discussion as the commit is from him.
Le 20/10/2019 à 11:53, Andreas Schwab a écrit :
On Okt 20 2019, Christophe Leroy wrote:
Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
On Okt 19 2019, Christophe Leroy wrote:
Hi Nathan,
While trying to switch powerpc VDSO to C v
On Okt 20 2019, Christophe Leroy wrote:
> Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
>> On Okt 19 2019, Christophe Leroy wrote:
>>
>>> Hi Nathan,
>>>
>>> While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
>>> getting the following kind of error with vdsotest:
>>>
>>> pa
Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
On Okt 19 2019, Christophe Leroy wrote:
Hi Nathan,
While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
getting the following kind of error with vdsotest:
passing NULL to clock_getres (VDSO): terminated by unexpected signa
On Mon, 2019-10-14 at 16:51:28 UTC, Christophe Leroy wrote:
> Make sure starting addr is aligned to segment boundary so that when
> incrementing the segment, the starting address of the new segment is
> below the end address. Otherwise the last segment might get missed.
>
> Fixes: a68c31fc01ef ("
20 matches
Mail list logo
