Hi,
These patches simplify some of the early memory allocations by replacing
usage of older memblock APIs with newer and shinier ones.
Quite a few places in the arch/ code allocated memory using a memblock API
that returns a physical address of the allocated area, then converted this
physical add
There are a several places that allocate memory using memblock APIs that
return a physical address, convert the returned address to the virtual
address and frequently also memset(0) the allocated range.
Update these places to use memblock allocators already returning a virtual
address. Use membloc
Rather than use the memblock_alloc_base that returns a physical address and
then convert this address to the virtual one, use appropriate memblock
function that returns a virtual address.
Signed-off-by: Mike Rapoport
Tested-by: Michal Simek
---
arch/microblaze/mm/init.c | 5 +++--
1 file change
Rather than use the memblock_alloc_base that returns a physical address and
then convert this address to the virtual one, use appropriate memblock
function that returns a virtual address.
There is a small functional change in the allocation of then NODE_DATA().
Instead of panicing if the local all
The pte_alloc_one_kernel() function allocates a page using
__get_free_page(GFP_KERNEL) when mm initialization is complete and
memblock_phys_alloc() on the earlier stages. The physical address of the
page allocated with memblock_phys_alloc() is converted to the virtual
address and in the both cases
There are several early memory allocations in arch/ code that use
memblock_phys_alloc() to allocate memory, convert the returned physical
address to the virtual address and then set the allocated memory to zero.
Exactly the same behaviour can be achieved simply by calling
memblock_alloc(): it allo
arm, s390 and unicore32 use oneliner wrappers for memblock_alloc().
Replace their usage with direct call to memblock_alloc().
Suggested-by: Christoph Hellwig
Signed-off-by: Mike Rapoport
---
arch/arm/mm/mmu.c | 11 +++
arch/s390/numa/numa.c | 10 +-
arch/unicore32/mm/mmu
On Sun, Dec 30, 2018 at 8:25 AM Finn Thain wrote:
>
> On Sat, 29 Dec 2018, Arnd Bergmann wrote:
>
> > > --- a/drivers/char/nvram.c
> > > +++ b/drivers/char/nvram.c
> > > @@ -48,6 +48,10 @@
> > > #include
> > > #include
> > >
> > > +#ifdef CONFIG_PPC
> > > +#include
> > > +#include
> > > +#en
On Mon, Dec 31, 2018 at 12:13 AM Finn Thain wrote:
> On Sun, 30 Dec 2018, Finn Thain wrote:
> > > > diff --git a/include/linux/nvram.h b/include/linux/nvram.h
> > > > index b7bfaec60a43..24a57675dba1 100644
> > > > --- a/include/linux/nvram.h
> > > > +++ b/include/linux/nvram.h
> > > > @@ -18,8 +1
On Sun, Dec 30, 2018 at 11:12 PM Finn Thain wrote:
> On Sun, 30 Dec 2018, LEROY Christophe wrote:
> But I'm over-simplifying. Arnd's alternative actually goes like this,
>
> #if defined(CONFIG_MAC) && !defined(CONFIG_ATARI)
> const struct nvram_ops arch_nvram_ops = {
> /* ... */
> }
> #el
On Sun, Dec 30, 2018 at 5:05 AM Finn Thain wrote:
>
> On Sun, 30 Dec 2018, I wrote:
>
> >
> > I'm not opposed to exported functions in place of a singleton ops
> > struct. Other things being equal I'm inclined toward the ops struct,
> > perhaps because I like encapsulation or perhaps because I don
On Sun, Dec 30, 2018 at 12:43 AM Finn Thain wrote:
>
> Is there some benefit, or is that just personal taste?
>
> Avoiding changes to call sites avoids code review, but I think 1) the
> thinkpad_acpi changes have already been reviewed and 2) the fbdev changes
> need review anyway.
>
> Your sugges
On Sun, Dec 30, 2018 at 4:29 AM Finn Thain wrote:
>
> On Sat, 29 Dec 2018, Arnd Bergmann wrote:
>
> > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > wrote:
> >
> > > +static ssize_t ppc_nvram_get_size(void)
> > > +{
> > > + if (ppc_md.nvram_size)
> > > + return ppc_md.nvram_s
On 12/30/18 10:44 PM, Finn Thain wrote:
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Finn Thain
Applied, thanks.
--
Jens Axboe
On 12/30/18 10:44 PM, Finn Thain wrote:
> When the block device is opened with FMODE_EXCL, ref_count is set to -1.
> This value doesn't get reset when the device is closed which means the
> device cannot be opened again. Fix this by checking for refcount <= 0
> in the release method.
Applied, than
On 12/30/18 10:44 PM, Finn Thain wrote:
> As of v4.20, the swim3 driver crashes when loaded on a PowerBook G3
> (Wallstreet).
>
> MacIO PCI driver attached to Gatwick chipset
> MacIO PCI driver attached to Heathrow chipset
> swim3 0.00015000:floppy: [fd0] SWIM3 floppy controller in media bay
> 0.0
Commit 33a48ab105a7 ("ibmveth: Fix DMA unmap error") fixed an issue in the
normal code path of ibmveth_xmit_start() that was originally introduced by
Commit 6e8ab30ec677 ("ibmveth: Add scatter-gather support"). This original
fix missed the error path where dma_unmap_page is wrongly called on the
he
On Sun, 30 Dec 2018, I wrote:
>
> The rationale for the ops struct was that it offers introspection.
>
> [...] those platforms which need checksum validation always set
> byte-at-a-time methods to NULL.
>
> [...] The NULL methods in the ops struct allow the nvram.c misc device
> to avoid inef
On Thu, 2018-12-27 at 11:05 -0800, Guenter Roeck wrote:
> Hi,
>
> I am getting the attached runtime warnings when enabling certain debug
> options in powerpc code. The warnings are seen with pretty much all
> platforms, and all active kernel releases.
>
> Question: Is it worthwhile to keep buildi
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 8:25 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > > --- a/drivers/char/nvram.c
> > > > +++ b/drivers/char/nvram.c
> > > > @@ -48,6 +48,10 @@
> > > > #include
> > > > #include
> > > >
> > >
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 12:43 AM Finn Thain
> wrote:
>
> >
> > Is there some benefit, or is that just personal taste?
> >
> > Avoiding changes to call sites avoids code review, but I think 1) the
> > thinkpad_acpi changes have already been reviewed an
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 4:29 AM Finn Thain wrote:
> >
> > On Sat, 29 Dec 2018, Arnd Bergmann wrote:
> >
> > > On Wed, Dec 26, 2018 at 1:43 AM Finn Thain
> > > wrote:
> > >
> > > > +static ssize_t ppc_nvram_get_size(void)
> > > > +{
> > > > + if
Old GCCs (4.6.3 at least), aren't able to follow the logic in
__kvmhv_copy_tofrom_guest_radix() and warn that old_pid is used
uninitialized:
arch/powerpc/kvm/book3s_64_mmu_radix.c:75:3: error: 'old_pid' may be
used uninitialized in this function
The logic is OK, we only use old_pid if quadran
Currently the code produces several warnings, eg:
arch/powerpc/platforms/4xx/ocm.c:240:38: error: format '%llx'
expects argument of type 'long long unsigned int', but argument 3
has type 'phys_addr_t {aka unsigned int}'
seq_printf(m, "PhysAddr : 0x%llx\n", ocm->phys);
There was recently a compilation break to this driver, but we didn't
notice because none of our defconfigs have it enabled. Fix that.
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/ppc40x_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/ppc40x_defconfi
25 matches
Mail list logo
