In commit c60ac5693c47 ("powerpc: Update kernel VSID range", 2013-03-13)
we lost a check on the region number (the top four bits of the effective
address) for addresses below PAGE_OFFSET. That commit replaced a check
that the top 18 bits were all zero with a check that bits 46 - 59 were
zero (perf
This replaces a 2-D search through an array with a simple 8-bit table
lookup for determining the actual and/or base page size for a HPT entry.
The encoding in the second doubleword of the HPTE is designed to encode
the actual and base page sizes without using any more bits than would be
needed for
Currently, if userspace or the kernel accesses a completely bogus address,
for example with any of bits 46-59 set, we first take an SLB miss interrupt,
install a corresponding SLB entry with VSID 0, retry the instruction, then
take a DSI/ISI interrupt because there is no HPT entry mapping the addre
Hi Paul,
Really nice catch. Was this found by code analysis or do we have any
reported issue around this ?
Paul Mackerras writes:
> In commit c60ac5693c47 ("powerpc: Update kernel VSID range", 2013-03-13)
> we lost a check on the region number (the top four bits of the effective
> address) for
Hi Dave,
On Thu, 2016-09-01 at 09:57 +0800, Dave Young wrote:
> On 08/30/16 at 06:40pm, Mimi Zohar wrote:
> > + * Called during kexec_file_load so that IMA can add a segment to the kexec
> > + * image for the measurement list for the next kernel.
> > + */
> > +void ima_add_kexec_buffer(struct kim
From: Colin Ian King
Trivial fix to spelling mistakes in dev_dbg messages
Signed-off-by: Colin Ian King
---
sound/soc/fsl/fsl_esai.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 26a90e1..e927955 100644
--- a
On Fri, Sep 02, 2016 at 03:07:23PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistakes in dev_dbg messages
>
> Signed-off-by: Colin Ian King
Acked-by: Nicolin Chen
Thanks
> ---
> sound/soc/fsl/fsl_esai.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 dele
On Wed, Aug 24, 2016 at 10:17:38AM +0200, Gabriel Paubert wrote:
> On Tue, Aug 23, 2016 at 05:45:04PM -0700, mcg...@kernel.org wrote:
>
> [snip]
> > ---
> > Documentation/firmware_class/README| 20
> > drivers/base/Kconfig | 2 +-
> > .../requ
On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann wrote:
>
> When I once looked, I thought all drivers using NO_IRQ were specific
> to powerpc or one of the less common architectures.
powerpc definitely does seem to be the biggest case, with about half
the instances of NO_IRQ being under arch/powerpc
This patch set contains miscellaneous fixes in the device cleanup and
EEH recovery paths. One of the patches simplifies the WWPN assignment
routine.
There are a couple of fixes that resolve regressions introduced by
Commit 704c4b0ddc03 ("cxlflash: Shutdown notify support for CXL Flash
cards") and
When a port link is established, the AFU sends a 'link up' interrupt.
After the link is up, corresponding initialization steps are performed
on the card. Following that, when the card is ready for I/O, the AFU
sends 'login succeeded' interrupt. Today, cxlflash invokes
scsi_scan_host() upon receipt
Commit 704c4b0ddc03 ("cxlflash: Shutdown notify support for CXL Flash
cards") was recently introduced to notify the AFU when a system is going
down. Due to the position of the cxlflash driver in the device stack,
cxlflash devices are _always_ removed during a reboot/shutdown. This can
lead to a cra
From: "Matthew R. Ochs"
The EEH reset handler is ignorant to the current state of the
driver when processing a frozen event and initiating a device
reset. This can be an issue if an EEH event occurs while a user
or stack initiated reset is executing. More specifically, if an
EEH occurs while the
From: "Matthew R. Ochs"
When an EEH occurs during device initialization, the port timeout
logic can cause excessive delays as MMIO reads will fail. Depending
on where they are experienced, these delays can lead to a prolonged
reset, causing an unnecessary triggering of other timeout logic in
the
From: "Matthew R. Ochs"
Commit 964497b3bf3f ("cxlflash: Remove dual port online dependency")
logically removed the ability for the WWPN setup routine afu_set_wwpn()
to return a non-success value. This routine can safely be made a void
to simplify the code as there is no longer a need to report a
From: "Matthew R. Ochs"
Commit 888baf069f49 ("scsi: cxlflash: Add kref to context") introduced a
kref to the context. In particular, the detach routine was updated to use
the kref services for managing the removal and destruction of a context.
As part of this change, the tracking mechanism inter
On Fri, 2 Sep 2016, Linus Torvalds wrote:
> On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann wrote:
> >
> > When I once looked, I thought all drivers using NO_IRQ were specific
> > to powerpc or one of the less common architectures.
>
> powerpc definitely does seem to be the biggest case, with abo
On Fri, Sep 2, 2016 at 1:43 PM, Julia Lawall wrote:
>
> Like this?
Sure.
> Is it always correct to replace return NO_IRQ by return 0?
On platforms that define it to 0, like powerpc, yes.
On arm, c6x, mn10300, parisc and sparc it would need more work.
> Completely untested patch below.
Looks
On Fri, 2016-09-02 at 13:26 -0700, Linus Torvalds wrote:
> On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann wrote:
> >
> >
> > When I once looked, I thought all drivers using NO_IRQ were
> > specific
> > to powerpc or one of the less common architectures.
We deprecated NO_IRQ ages ago, it's 0 like
On Thu, Aug 25, 2016 at 09:41:33PM +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez
> > wrote:
> > Some users want a fully running gfx stack 2s after power-on. There's
> > not even enough time
kernel_read_file_from_path() can try to read a file from
the system's filesystem. This is typically done for firmware
for instance, which lives in /lib/firmware. One issue with
this is that the kernel cannot know for sure when the real
final /lib/firmare/ is ready, and even if you use initramfs
dri
On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote:
>
> Thoughts ?
I really think this is a horrible hack.
It's basically the kernel giving up, and relying on user space to give
a single flag, and it's broken nasty crap. Worse, it's broken nasty
crap with a user interface, so we'll be stuc
On Fri, Sep 2, 2016 at 9:11 PM, Linus Torvalds
wrote:
> On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote:
>>
>> Thoughts ?
>
> I really think this is a horrible hack.
>
> It's basically the kernel giving up, and relying on user space to give
> a single flag, and it's broken nasty crap. Wo
23 matches
Mail list logo
