Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my
PowerBook G4 Aluminum. The bootstrap loads the initial kernel and issues
the appropriate start, but the machine hangs at that point.
Can you please be more explicit ? What do you me
Hi Christophe,
On Sat, Mar 23, 2019 at 5:27 PM LEROY Christophe
wrote:
>
> Arnd Bergmann a écrit :
>
> > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> >>
> >> I've added your patch to my randconfig test setup and will let you
> >> know if I see anything noticeable. I'm currently test
Hi Heiko,
On Thu, Mar 21, 2019 at 5:02 PM Heiko Carstens
wrote:
>
> On Wed, Mar 20, 2019 at 03:20:27PM +0900, Masahiro Yamada wrote:
> > Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
> > CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
> >
> > The idea is obviou
On Friday, March 22, 2019 6:07:24 PM IST Michael Ellerman wrote:
> Chandan reported that fstests' generic/026 test hit a crash:
>
> BUG: Unable to handle kernel data access at 0xc0062ac4
> Faulting instruction address: 0xc0092240
> Oops: Kernel access of bad area, sig: 11 [#1
On Friday, March 22, 2019 6:07:24 PM IST Michael Ellerman wrote:
> Chandan reported that fstests' generic/026 test hit a crash:
>
> BUG: Unable to handle kernel data access at 0xc0062ac4
> Faulting instruction address: 0xc0092240
> Oops: Kernel access of bad area, sig: 11 [#1
On Mon, Mar 25, 2019 at 3:10 PM Masahiro Yamada
wrote:
>
> Hi Arnd,
>
>
>
>
> On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> > >
> > > I've added your patch to my randconfig test setup and will let you
> > > know if I see any
Hi Arnd,
On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
>
> On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> >
> > I've added your patch to my randconfig test setup and will let you
> > know if I see anything noticeable. I'm currently testing clang-arm32,
> > clang-arm64 and gcc
Hi Arnd,
On Wed, Mar 20, 2019 at 10:05 PM Arnd Bergmann wrote:
>
> On Wed, Mar 20, 2019 at 11:19 AM Masahiro Yamada
> wrote:
> > On Wed, Mar 20, 2019 at 6:39 PM Arnd Bergmann wrote:
> > >
> > > On Wed, Mar 20, 2019 at 7:41 AM Masahiro Yamada
> > > wrote:
> > >
> > > > It is unclear to me ho
From: Alastair D'Silva
External drivers that communicate via OpenCAPI will need to make
MMIO calls to interact with the devices.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/Makefile | 2 +-
drivers/misc/ocxl/mmio.c | 234 +++
From: Alastair D'Silva
Event_fd is only used in the driver frontend, so it does not
need to exist in the backend code. Relocate it to the frontend
and provide an opaque mechanism for consumers instead.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/afu_irq.c | 76 +
From: Alastair D'Silva
The use of offsets is required only in the frontend, so alter
the IRQ API to only work with IRQ IDs in the backend.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/afu_irq.c | 34 +++
drivers/misc/ocxl/context.c | 7 +--
From: Alastair D'Silva
Most OpenCAPI operations require a valid context, so
exposing these functions to external drivers is necessary.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/context.c | 9 +--
drivers/misc/ocxl/file.c | 2 +-
drivers/
From: Alastair D'Silva
The OCXL driver contains both frontend code for interacting with userspace,
as well as backend code for interacting with the hardware.
This patch separates the backend code from the frontend so that it can be
used by other device drivers that communicate via OpenCAPI.
Rel
From: Alastair D'Silva
This data is already available in a struct
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
index
From: Alastair D'Silva
In preparation for making core code available for external drivers,
move the core code out of pci.c and into core.c
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/Makefile| 1 +
drivers/misc/ocxl/core.c | 517 +
drive
From: Alastair D'Silva
Changelog:
V3:
- For: 'ocxl: Create a clear delineation between ocxl backend & frontend'
- Integrate Frederick Barrat's suggestions
- Further cleanup on error paths
- Remove release handler for AFU private data
- Make ocxl_file_make_(in)visibile st
From: Alastair D'Silva
The term 'link' is ambiguous (especially when the struct is used for a
list), so rename it for clarity.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/file.c | 5 ++---
drivers/misc/ocxl/link.c | 36 ++--
2
From: Alastair D'Silva
Remove some unused exported symbols.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 4 +---
drivers/misc/ocxl/ocxl_internal.h | 23 +++
include/misc/ocxl.h | 23 ---
3 files changed, 24 inser
From: Alastair D'Silva
The 'extern' keyword adds no value here.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/ocxl_internal.h | 54 +++
include/misc/ocxl.h | 36 ++---
2 files changed, 44 insertions(+), 46 deletions(-)
diff --g
From: Alastair D'Silva
No need for a return value in read_pasid as it only returns 0.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
drivers/misc/ocxl/config.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/oc
From: Alastair D'Silva
Some minor cleanups for the OpenCAPI driver as a prerequisite
for an ocxl driver refactoring to allow the driver core to
be utilised by external drivers.
Changelog:
V4:
- Drop printf format changes as they omit the format indicator for '0'
V3:
- Add missed header in 'o
On Sat, Mar 23, 2019 at 05:01:35PM -0400, Michael S. Tsirkin wrote:
> On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote:
> > Michael S. Tsirkin writes:
[snip]
> > >> > Is there any justification to doing that beyond someone putting
> > >> > out slow code in the past?
> > >>
> >
On Mon, 2019-03-25 at 01:03 +0100, Andreas Schwab wrote:
> On Mär 24 2019, Ben Hutchings wrote:
>
> > Presumably you have CONFIG_PPC_BOOK3S_64 enabled and
> > CONFIG_SPARSEMEM
> > disabled? Was this configuration actually usable?
>
> Why not?
I assume that CONFIG_SPARSEMEM is the default for a
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
The problem does not depend on the choice of PPC32 processor type. This machine
has a 7447A accor
On Mär 24 2019, Ben Hutchings wrote:
> Presumably you have CONFIG_PPC_BOOK3S_64 enabled and CONFIG_SPARSEMEM
> disabled? Was this configuration actually usable?
Why not?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
On Sun, 2019-03-24 at 23:18 +0100, Andreas Schwab wrote:
> On Mär 22 2019, Michael Ellerman wrote:
>
> > On Sun, 2019-03-17 at 01:17:56 UTC, Ben Hutchings wrote:
> > > MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
> > > enabled, and that was the case before commit 4ffe713b7587
On Mär 22 2019, Michael Ellerman wrote:
> On Sun, 2019-03-17 at 01:17:56 UTC, Ben Hutchings wrote:
>> MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
>> enabled, and that was the case before commit 4ffe713b7587
>> ("powerpc/mm: Increase the max addressable memory to 2PB").
>>
>>
On 19/03/2019 23:25:31+0800, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warning:
>
> drivers/rtc/rtc-opal.c:227:5:
> warning: symbol 'opal_tpo_alarm_irq_enable' was not declared. Should it be
> static?
>
> Signed-off-by: YueHaibing
> ---
> drivers/rtc/rtc-opal.c | 2 +-
> 1 file c
28 matches
Mail list logo
