Benjamin Herrenschmidt writes:
> On Wed, 2016-04-27 at 11:00 +1000, Balbir Singh wrote:
>> Just basic testing across CPUs with various mm features
>> enabled/disabled. Just for sanity
>
> I still don't think it's worth scattering the change. Either the jump
> label works or it doesn't ... The on
Hi Arnd,
On Tue, Apr 26, 2016 at 11:52 PM, Arnd Bergmann wrote:
> The rtc-generic driver provides an architecture specific
> wrapper on top of the generic rtc_class_ops abstraction,
> and m68k has another abstraction on top, which is a bit
> silly.
>
> This changes the m68k rtc-generic device to
Hi Arnd,
On Tue, Apr 26, 2016 at 11:52 PM, Arnd Bergmann wrote:
> This is a resend of an earlier series, to clean up the rtc-generic
> driver by avoiding the dependency on the architecture specific
> include/asm/rtc.h header that after this series is only used
> for the deprecated "genrtc" driver
Hi Arnd,
On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann wrote:
> For the genrtc driver, rearranging the headers makes it simpler
> to use and reduces duplication. In case of alpha and mn10300,
> I've shown that the genrtc and rtc drivers are doing the same
> thing, so we don't need them both. Th
On 27/04/16 15:03, Stewart Smith wrote:
> Suraj Jitindar Singh writes:
>> Add a binding to Documentation/devicetree/bindings/powerpc/opal
>> (oppanel-opal.txt) for the operator panel which is present on IBM
>> pseries machines with FSPs.
> It's not pseries (as that implies PowerVM / PAPR) - while
On 26/04/2016 at 23:44:05 +0200, Arnd Bergmann wrote :
> Every new architecture has to add itself to the growing list of those
> that do not support the legacy PC RTC driver.
>
> This replaces the long list of architectures that don't support it
> with a shorter list of those that do.
>
> The lis
On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
> Hi Arnd,
>
> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann wrote:
> > For the genrtc driver, rearranging the headers makes it simpler
> > to use and reduces duplication. In case of alpha and mn10300,
> > I've shown that the genrtc
Add support for the Artesyn MVME7100 Single Board Computer.
The MVME7100 is a 6U form factor VME64 computer with:
- A two e600 cores Freescale MPC8641D CPU
- 2 GB of DDR2 onboard memory
- Four Gigabit Ethernets
- Five 16550 compatible UARTs
- One USB 2.0 port
- Two PCI/PCI
On 26/04/2016 at 23:44:06 +0200, Arnd Bergmann wrote :
> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain
Hi Arnd,
On Wed, Apr 27, 2016 at 10:33 AM, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 09:54:41 Geert Uytterhoeven wrote:
>> On Tue, Apr 26, 2016 at 11:44 PM, Arnd Bergmann wrote:
>> > For the genrtc driver, rearranging the headers makes it simpler
>> > to use and reduces duplication. In c
On 26/04/2016 at 23:44:07 +0200, Arnd Bergmann wrote :
> Nothing on these architectures ever includes the asm/mc146818rtc.h
> file, the drivers that used to do this have been fixed long ago,
> and the remaining users are all PC-specific.
>
> This removes the files for good.
>
> Signed-off-by: Arn
From: Pan Xinhui
Implement xchg{u8,u16}{local,relaxed}, and
cmpxchg{u8,u16}{,local,acquire,relaxed}.
It works on all ppc.
remove volatile of first parameter in __cmpxchg_local and __cmpxchg
Suggested-by: Peter Zijlstra (Intel)
Signed-off-by: Pan Xinhui
---
change from v3:
rewrite in
The subject should be:
rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h
Else, you can add:
Acked-by: Alexandre Belloni
On 26/04/2016 at 23:44:08 +0200, Arnd Bergmann wrote :
> Drivers should not really include stuff from asm-generic directly,
> and the PC-style cmos rtc driver does thi
"Aneesh Kumar K.V" writes:
> Benjamin Herrenschmidt writes:
>
>> On Wed, 2016-04-27 at 11:00 +1000, Balbir Singh wrote:
>>> Just basic testing across CPUs with various mm features
>>> enabled/disabled. Just for sanity
>>
>> I still don't think it's worth scattering the change. Either the jump
>
On Thu, Apr 21, 2016 at 01:48:42PM +0200, Petr Mladek wrote:
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index cdfa6c2b7626..259543ec6dc9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -66,6 +66,7 @@ config ARM
> select HAVE_KRETPROBES if (HAVE_KPROBES)
> select
On Thu, Apr 21, 2016 at 01:48:43PM +0200, Petr Mladek wrote:
> @@ -64,8 +65,10 @@ static int vprintk_nmi(const char *fmt, va_list args)
> again:
> len = atomic_read(&s->len);
>
> - if (len >= sizeof(s->buffer))
> + if (len >= sizeof(s->buffer)) {
> + atomic_inc(&nmi_mes
On Tue, 26 Apr 2016, Balbir Singh wrote:
> > + + Anything inlined into __schedule() can not be patched.
> > +
> > +The switch_to macro is inlined into __schedule(). It switches the
> > +context between two processes in the middle of the macro. It does
> > +not save RIP in x86_64 versi
On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> I've had these patches in my tree for a while, after the first one
> had a few issues that are fixed in this new version. The old-style
> PC RTC driver is now also disabled on m68k (as pointed out by
> Geert), ppc (it was also blacklisted), a
On Wednesday 27 April 2016 11:29:12 Alexandre Belloni wrote:
> The subject should be:
> rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h
Good point, the functions are only used by rtc-cmos, not the old
drivers/char/rtc.c.
> Else, you can add:
> Acked-by: Alexandre Belloni
Thanks.
On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
> > I've had these patches in my tree for a while, after the first one
> > had a few issues that are fixed in this new version. The old-style
> > PC RTC driver is now also disabled
On Wednesday 27 April 2016 08:22:24 kbuild test robot wrote:
>
>256
>257 memset(tm, 0, sizeof(*tm));
>258 if (pdc_tod_read(&tod_data) < 0)
>259 return -EOPNOTSUPP;
>260
>261 /* we treat tod_sec as unsigned, so this can work un
Hi Arnd,
On Wed, Apr 27, 2016 at 12:07 PM, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 11:44:10 Alexandre Belloni wrote:
>> On 26/04/2016 at 23:44:04 +0200, Arnd Bergmann wrote :
>> > I've had these patches in my tree for a while, after the first one
>> > had a few issues that are fixed in
On Tue, 26 Apr 2016, Arnd Bergmann wrote:
> Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
> the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
> which in turn disables the selection of the CONFIG_RTC and
> CONFIG_GEN_RTC drivers that contain a two older
On Wednesday 27 April 2016 09:47:56 Geert Uytterhoeven wrote:
> > --- a/arch/m68k/kernel/time.c
> > +++ b/arch/m68k/kernel/time.c
> > @@ -86,7 +86,24 @@ void read_persistent_clock(struct timespec *ts)
> > }
> > }
> >
> > -#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
> > +#if defined(CONFIG_ARCH_U
On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> Arnd Bergmann wrote:
> > The asm-generic/rtc.h header can now be included by
> > architectures that provide their own set_rtc_time/get_rtc_time
> > macros, letting us remove most of the common contents in
> > the powerpc implementation.
>
On Wednesday 27 April 2016 12:19:59 Geert Uytterhoeven wrote:
> >
> > Right, so we could skip patches 5 and 6, and instead remove the two
> > headers as we remove the driver. Let's see what the architecture
> > maintainers think about it, at least powerpc actually enables gen_rtc
> > in its defconf
On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> > Arnd Bergmann wrote:
> > > The asm-generic/rtc.h header can now be included by
> > > architectures that provide their own set_rtc_time/get_rtc_time
> > > macros, letting us remov
On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
>> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
>> > Arnd Bergmann wrote:
>> > > The asm-generic/rtc.h header can now be included by
>> > > architectures that provide their
The resource_alignment will releases memory resources allocated
by firmware so that kernel can reassign new resources later on.
But this will cause the problem that no resources can be
allocated by kernel if PCI_PROBE_ONLY was set, e.g. on pSeries
platform because PCI_PROBE_ONLY force kernel to use
This series aims to add an option for PCI resource allocator to
force BARs not to share PAGE_SIZE. This would make sense to VFIO
driver. Because current VFIO implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs which may share the same page
with other BARs for security reasons.
Now we use the IORESOURCE_STARTALIGN to identify bridge resources
in __assign_resources_sorted(). That's quite fragile. We can't
make sure that the PCI devices' resources will not use
IORESOURCE_STARTALIGN any more.
In this patch, we try to use a more robust way to identify
bridge resources.
Sign
When vfio passthrough a PCI device of which MMIO BARs are
smaller than PAGE_SIZE, guest will not handle the mmio
accesses to the BARs which leads to mmio emulations in host.
This is because vfio will not allow to passthrough one BAR's
mmio page which may be shared with other BARs. Otherwise,
there
When using resource_alignment kernel parameter, the current
implement reassigns the alignment by changing resources' size
which can potentially break some drivers. For example, the driver
uses the size to locate some register whose length is related
to the size.
This patch adds a new option "nores
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio
page may be shared with other BARs. This will cause some
performance issues when we passthrough a PCI device with
this kind of BARs. Guest will be not able to handle the mmio
accesses to
The capability of IRQ remapping is abstracted on IOMMU side on
some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.
To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when IOMMU_CAP_INTR_REMAP is set.
Signe
On Wednesday 27 April 2016 13:55:43 Geert Uytterhoeven wrote:
> On Wed, Apr 27, 2016 at 1:35 PM, Arnd Bergmann wrote:
> > On Wednesday 27 April 2016 13:21:16 Arnd Bergmann wrote:
> >> On Wednesday 27 April 2016 00:07:47 Rolf Eike Beer wrote:
> >> > Arnd Bergmann wrote:
> >> > > The asm-generic/rtc
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write to MSI-X
table and generate an incorrect MSIs.
However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table. We have
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 tables of PCI BARs to userspace. Because the capability
of IRQ
This patch enables mmapping MSI-X tables if hardware supports
interrupt remapping which can ensure that a given pci device
can only shoot the MSIs assigned for it.
With MSI-X table mmapped, we also need to expose the
read/write interface which will be used to access MSI-X table.
Signed-off-by: Yo
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/po
On ARM HW the capability of IRQ remapping is abstracted on
MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise
this [1].
To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when MSI_FLAG_IRQ_REMAPPING is set.
On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote:
> From: Pan Xinhui
>
> Implement xchg{u8,u16}{local,relaxed}, and
> cmpxchg{u8,u16}{,local,acquire,relaxed}.
>
> It works on all ppc.
>
> remove volatile of first parameter in __cmpxchg_local and __cmpxchg
>
> Suggested-by: Peter Zijl
On Wed, Apr 27, 2016 at 09:58:17PM +0800, Boqun Feng wrote:
> On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote:
> > From: Pan Xinhui
> >
> > Implement xchg{u8,u16}{local,relaxed}, and
> > cmpxchg{u8,u16}{,local,acquire,relaxed}.
> >
> > It works on all ppc.
> >
> > remove volatile of
On Wed, Apr 27, 2016 at 09:58:17PM +0800, Boqun Feng wrote:
> On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote:
> > From: Pan Xinhui
> >
> > Implement xchg{u8,u16}{local,relaxed}, and
> > cmpxchg{u8,u16}{,local,acquire,relaxed}.
> >
> > It works on all ppc.
> >
> > remove volatile of
On Wed, Apr 27, 2016 at 10:50:34PM +0800, Boqun Feng wrote:
>
> Sorry, my bad, we can't implement cmpxchg like this.. please ignore
> this, I should really go to bed soon...
>
> But still, we can save the "tmp" for xchg() I think.
>
No.. we can't. Sorry for all the noise.
This patch looks good
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
On 2016/04/12 02:40PM, Naveen N Rao wrote:
> This patchset fixes three issues found with perf probe on ppc64le:
> 1. 'perf test kallsyms' failure on ppc64le (reported by Michael
> Ellerman). This was due to the symbols being fixed up during symbol
> table load. This is fixed in patch 2 by delaying
+++ Petr Mladek [25/04/16 17:14 +0200]:
LivePatch framework deserves some documentation, definitely.
This is an attempt to provide some basic info. I hope that
it will be useful for both LivePatch producers and also
potential developers of the framework itself.
Signed-off-by: Petr Mladek
Nice
On Mon, 25 Apr 2016, Petr Mladek wrote:
> LivePatch framework deserves some documentation, definitely.
> This is an attempt to provide some basic info. I hope that
> it will be useful for both LivePatch producers and also
> potential developers of the framework itself.
>
> Signed-off-by: Petr Mla
On Tue, 26 Apr 2016, Chris J Arges wrote:
[ ... snip ... ]
> > + + Kretprobes using the ftrace framework conflict with the patched
>
> + + Kretprobes using the ftrace framework conflicts with the patched
Chris,
I've incorporated all your feedback except for this one; are you really
sure abo
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 vague; if you
hello
every time i try to compile the linux kernel with arch=powerpc i got this
error
WRAP arch / powerpc / boot / zImage.pseries
powerpc-linux-gnu-ld: unrecognized emulation mode: -T
Emulations supported: elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf32_spu
make [1]: *** [arch / powerpc / boot /
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and on pa-risc, that is implemented using an open-coded
version of rtc_time_to_tm/rtc_tm_to_time.
This changes the parisc rtc-generic device to provide its
rtc_class_ops directly, usin
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and on sh, that goes through another indirection using
the rtc_sh_get_time/rtc_sh_set_time functions.
This changes the sh rtc-generic device to provide its
rtc_class_ops directly, skip
This architecture selects RTC_CLASS unconditionally, so the GEN_RTC
has not worked here for a long time.
Now we can remove both the asm/rtc.h header and the Kconfig dependency
for CONFIG_GEN_RTC.
Signed-off-by: Arnd Bergmann
---
arch/parisc/include/asm/rtc.h | 131 --
No architecture uses the genrtc driver any more, so let's kill it off
for good. This now also includes asm-generic/rtc.h, which is otherwise
completely unused.
Signed-off-by: Arnd Bergmann
---
drivers/char/Kconfig | 26 ---
drivers/char/Makefile | 1 -
drivers/char/genrtc.c | 539
The asm/rtc.h header is only used for the old gen_rtc driver
that has been replaced by rtc-generic. According to Geert
Uytterhoeven, nobody has used the old driver on m68k for
a long time, so we can now just remove the header file
and disallow the driver in Kconfig.
All files that used to include
Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
which in turn disables the selection of the CONFIG_RTC and
CONFIG_GEN_RTC drivers that contain a two older implementations of
the CONFIG_RTC_DRV_CMOS driver.
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and powerpc has another abstraction on top, which is a bit
silly.
This changes the powerpc rtc-generic device to provide its
rtc_class_ops directly, to reduce the number of layers
by o
The q40 platform is the only machine in the kernel that provides
RTC_PLL_GET/RTC_PLL_SET ioctl commands in its rtc through the
mach_get_rtc_pll/mach_set_rtc_pll callbacks.
However, this currenctly works only in the old-style genrtc
driver, not the (somewhat) modern rtc-generic driver replacing
it.
Nothing on these architectures ever includes the asm/mc146818rtc.h
file, the drivers that used to do this have been fixed long ago,
and the remaining users are all PC-specific.
This removes the files for good.
Signed-off-by: Arnd Bergmann
Acked-by: Alexandre Belloni
---
arch/frv/include/asm/mc
arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason,
and it works fine without that header, so lets remove the inclusion
in preparation of deleting the file.
Signed-off-by: Arnd Bergmann
---
arch/mips/sni/time.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/sni/
Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.
To make it more obvious what is
All architectures using this driver are now converted to
provide their own operations, so this one can be turned
into a trivial stub driver relying on its platform data.
Signed-off-by: Arnd Bergmann
---
drivers/rtc/rtc-generic.c | 35 +--
1 file changed, 1 inserti
The genrtc driver serves no purpose on Alpha because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.
The defconfig uses CONFIG_RTC=y, so this driver is not used by default.
At one po
PowerPC is the last architecture using the GEN_RTC driver on some
machines, but we can migrate them all to using the RTC_DRV_GENERIC
driver instead now.
This moves over the CONFIG_GEN_RTC option from drivers/char into
arch/powerpc/platforms/Kconfig and makes it just select the
replacement driver i
The genrtc driver serves no purpose on mn10300 because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.
I assume it was initially only added for completeness when the
mn10300 port was
I ended up stuffing the two patch series into one, as they are now
more dependent on one another. This now thoroughly removes the
genrtc driver including the asm/rtc.h headers it uses. For all
architectures that still have a meaningful asm/rtc.h, this goes
through two stages:
1) make the rtc-gener
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and m68k has another abstraction on top, which is a bit
silly.
This changes the m68k rtc-generic device to provide its
rtc_class_ops directly, to reduce the number of layers
by one.
S
On Thursday 28 April 2016 00:34:23 Arnd Bergmann wrote:
> return -ENODEV;
>
> - pdev = platform_device_register_simple("rtc-generic", -1, NULL, 0);
> + /* or just call devm_rtc_device_register instead? */
Oops, I was planning to remove the comment here.
I probably ha
On Thu, Apr 28, 2016 at 12:34:18AM +0200, Arnd Bergmann wrote:
> The rtc-generic driver provides an architecture specific
> wrapper on top of the generic rtc_class_ops abstraction,
> and on sh, that goes through another indirection using
> the rtc_sh_get_time/rtc_sh_set_time functions.
>
> This ch
On Wed, Apr 27, 2016 at 03:25:59PM +, David Laight wrote:
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, whil
On 28/04/16 06:08, Jiri Kosina wrote:
> 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,
On Fri, 2016-22-04 at 04:57:48 UTC, Michael Neuling wrote:
> Keep IRQ mappings on context teardown. This won't leak IRQs as if we
> allocate the mapping again, the generic code will give the same
> mapping used last time.
>
> Doing this works around a race in the generic code. Masking the
> inter
On Fri, 2016-22-04 at 04:57:49 UTC, Michael Neuling wrote:
> When detaching contexts, we may still have interrupts in the system
> which are yet to be delivered to any CPU and be acked in the PSL.
> This can result in a subsequent unrelated process getting an spurious
> IRQ or an interrupt for a no
On Tue, 2016-19-04 at 12:23:36 UTC, Rui Salvaterra wrote:
> Wire up preadv2/pwritev2 in the same way as preadv/pwritev. Fixes two
> build warnings on ppc64.
>
> Signed-off-by: Rui Salvaterra
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/d701cca6744fe0d67c86346dcf
cheers
__
On Sat, 2016-09-04 at 06:14:02 UTC, "Aneesh Kumar K.V" wrote:
Missing change log.
> Signed-off-by: Aneesh Kumar K.V
>
> diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h
> b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> index bb3d8539bb1b..d915788d5074 100644
> --- a/arch/powerpc/incl
On Thu, Apr 21, 2016 at 01:37:59PM +1000, Michael Ellerman wrote:
> Testing done by Paul Mackerras has shown that with a modern compiler
> there is no negative effect on code generation from enabling
> STRICT_MM_TYPECHECKS.
>
> So remove the option, and always use the strict type definitions.
>
>
On Thu, 2016-04-21 at 11:56 +0200, Arnd Bergmann wrote:
> On Thursday 21 April 2016 13:37:59 Michael Ellerman wrote:
> > Testing done by Paul Mackerras has shown that with a modern compiler
> > there is no negative effect on code generation from enabling
> > STRICT_MM_TYPECHECKS.
> >
> > So remove
The validity of the property input argument to of_remove_property() is
never checked within the function and thus it is possible to pass a null
value. It happens that this will be picked up in __of_remove_property()
as no matching property of the device node will be found and thus an
error will be
After obtaining a property from of_find_property() and before calling
of_remove_property() most code checks to ensure that the property
returned from of_find_property() is not null. The previous patch
moved this check to the start of the function of_remove_property() in
order to avoid the case wher
The return value of of_get_property() isn't checked before it is passed
to the strstr() function, if it happens that the return value is null
then this will result in a null pointer being dereferenced.
Add a check to see if the return value of of_get_property() is null and
if it is continue straig
"Aneesh Kumar K.V" writes:
> pgtable_page_dtor for nohash is now moved to pte_fragment_free_mm()
>
This patch switch 4K linux page size config to use pte_t * type instead
of struct page * for pgtable_t. This simplifies the code a lot helps in
consolidating both 64k and 4k page allocator routin
vmalloc range differs between hash and radix config. Hence make
VMALLOC_START and related constants a variable which get
runtime initialized depending on hash or radix.
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/hash.h| 14 +++---
> arch/powerpc/in
"Aneesh Kumar K.V" writes:
How we swith mmu context differ between hash and radix. For hash we need
to switch the slb details and for radix we need to switch PID SPR.
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/mmu_context.h | 25 +
> arch/power
Balbir Singh writes:
> On 09/04/16 16:13, Aneesh Kumar K.V wrote:
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>> arch/powerpc/include/asm/mmu_context.h | 25 +
>> arch/powerpc/kernel/swsusp.c | 2 +-
>> arch/powerpc/mm/mmu_context_nohash.c | 3 ++-
>> drivers
"Aneesh Kumar K.V" writes:
For hash we create vmemmap mapping using bolted hash page table entries. For
radix
we fill the radix page table. The next patch will add the radix details
for creating vmemmap mappings.
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/h
When unregistering a crash_shutdown_handle in the function
crash_shutdown_unregister() the other handles are shifted down in the
array to replace the unregistered handle. The for loop assumes that the
last element in the array is null and uses this as the stop condition,
however in the case that th
Michael Ellerman writes:
> On Sat, 2016-09-04 at 06:14:02 UTC, "Aneesh Kumar K.V" wrote:
>
> Missing change log.
This add THP support for 4K linux page size config with Radix. We still
don't do THP with 4K linux page size and hash page table. Hash page
table needs a 16MB hugepage and we can't do
On 28/04/16 16:17, Suraj Jitindar Singh wrote:
> When unregistering a crash_shutdown_handle in the function
> crash_shutdown_unregister() the other handles are shifted down in the
> array to replace the unregistered handle. The for loop assumes that the
> last element in the array is null and use
90 matches
Mail list logo
