gt; for a very long time on those platforms.
>
> I tried to look around, but I did not find any mentions that CREATE_DUMB
> should only be used for RGB buffers. Is anyone outside the core
> developers even aware of it?
>
> If we don't use dumb buffers there, where do w
ext on 64 bit
>
> Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module text
> allocations on 64 bit.
>
> Link: https://lkml.kernel.org/r/20241023162711.2579610-9-r...@kernel.org
> Signed-off-by: Mike Rapoport (Microsoft)
> Reviewed-by
ic(size, align)\
> +__memblock_alloc_or_panic(size, align, __func__)
> +
> static inline void *memblock_alloc_raw(phys_addr_t size,
>phys_addr_t align)
> {
> diff --git a/init/main.c b/init/main.c
Gr{oetje,eeting}s,
uot; | sort | uniq -c | sort -rn |
> head -20
> 38494 struct device *dev
> 16388 struct net_device *dev
>4184 struct drm_device *dev
>2780 struct pci_dev *dev
>1916 struct comedi_device *dev
>1510 struct mlx5_core_dev *dev
> 1057 struct mlx4_dev *dev
in the
shmob_drm-specific subclasses of drm_{crtc,connector,plane} to "base".
https://lore.kernel.org/dri-devel/b3daca80f82625ba14e3aeaf2fca6dcefa056e47.1687423204.git.geert+rene...@glider.be
> Also the functions that deal with both a struct device and a struct
> drm_device ofte
> memcpy(new_pgd, swapper_pg_dir, PTRS_PER_PGD * sizeof(pgd_t));
> memset(new_pgd, 0, PAGE_OFFSET >> PGDIR_SHIFT);
> return new_pgd;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li
desc(pte))); \
> > } while (0)
> >
> > #endif /* _ASM_NIOS2_PGALLOC_H */
>
> Applied!
I don't think you can just apply this patch, as the new functions
were only introduced in [PATCH v4 05/34] of this series.
Gr{oetje,eeting}s,
Geert
t
> these to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle)
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Lin
Hi Adrian,
On Thu, Jun 1, 2023 at 9:28 AM John Paul Adrian Glaubitz
wrote:
> On Thu, 2023-06-01 at 09:20 +0200, Geert Uytterhoeven wrote:
> > On Wed, May 31, 2023 at 11:33 PM Vishal Moola (Oracle)
> > wrote:
> > > Part of the conversions to replace pgtable cons
pgd;
> + struct ptdesc *ptdesc = pagetable_alloc(GFP_DMA | GFP_NOWARN, 0);
>
> - new_pgd = (pgd_t *)__get_free_page(GFP_DMA | __GFP_NOWARN);
> - if (!new_pgd)
> + if (!ptdesc)
> return NULL;
> + new_pgd = (pgd_t *) ptdesc_addr
On Wed, May 31, 2023 at 11:33 PM Vishal Moola (Oracle)
wrote:
> Part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents. Also cleans up some spacing issues.
>
> Signed-off-by: Vishal Moola (Oracle)
LGTM, so
Reviewed-by: Geert Uytterhoeven
Gr{oe
s something completely different.
> > What do you think? If it seems like excessive churn, we can do it
> > as-is and still try to reduce the use of the index variable over time.
>
> I think _p has a precedent as well. But I can think about it a bit, maybe
> we can come up
inux-std.lds |1 -
> arch/m68k/kernel/vmlinux-sun3.lds | 1 -
FWIW
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical peop
n fact it does nothing],
> while it's machine_power_off() that should invoke the pm_power_off(), and
> thus, we can't convert platforms to the new API separately. There are only
> two platforms changed here, so it's not a big deal.
>
> Acked-by: Geert Uytterhoeve
Hi Dmitry,
On Tue, May 24, 2022 at 3:41 PM Dmitry Osipenko
wrote:
> On 5/24/22 16:14, Geert Uytterhoeven wrote:
> > On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> > wrote:
> >> Add kernel_can_power_off() helper that replaces open-coded checks of
> >> the glob
cy_pm_power_off() does not seem to
be called.
On arm32, both pm_power_off_prepare and pm_power_off are NULL.
On arm64, pm_power_off_prepare is NULL, and
pm_power_off is psci_sys_poweroff.
Do you have a clue?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Th
rc1, too?
I've sent a fix. It should appear at
https://lore.kernel.org/r/20220523175520.949681-1-ge...@linux-m68k.org
soon.
Can you please include that in your PR?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond
you forgot to add the actual acks?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalis
; >> We can't just change the registration order because invocation order of
> > >> the call chain depends on the registration order
> > >
> > > It doesn't if unique priorities are required and isn't that what you want?
> > >
> > >
to this module
> + from the default device drivers. The argument is the list of PCI
> BDFs:
> + xen-pciback.hide=(03:00.0)(04:00.0)
> +
> + If in doubt, say m.
> +
> config XEN_PCIDEV_BACKEND
> tristate "Xen PCI-device backend driv
Hi Borislav,
On Mon, Nov 8, 2021 at 4:59 PM Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> > I'm not against returning proper errors codes. I'm against forcing
> > callers to check things that cannot fail and to add indi
Hi Borislav,
On Mon, Nov 8, 2021 at 3:21 PM Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> > I think the addition of __must_check is overkill, leading to the
> > addition of useless error checks and message printing.
>
checks and message printing. Many callers
call this where it cannot fail, and where nothing can be done in the
very unlikely event that the call would ever start to fail.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux
n fact it does nothing],
> while it's machine_power_off() that should invoke the pm_power_off(), and
> thus, we can't convert platforms to the new API separately. There are only
> two platforms changed here, so it's not a big deal.
>
> Signed-off-by: Dmitry Osipenko
Acked-by: Gee
; implemented buses return an ignored error code and so don't anticipate
> wrong expectations for driver authors.
> drivers/zorro/zorro-driver.c | 3 +--
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There&#
sed uninitialized" warnings thrown up by gcc-4.1, until
(a bit later than) support for that compiler was removed...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal con
ig.bus | 2 +-
> arch/m68k/Kconfig.debug| 16
> arch/m68k/Kconfig.machine | 8 ++++
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Li
n added in the meantime so the patch is
> sufficient as itself on linux-next, too.
Do you know in which commit they became deprecated, so the backporters
know how far this can be backported safely?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There&
/mm/motorola.c | 9 +
> arch/m68k/mm/sun3mmu.c| 6 ++
> arch/m68k/sun3/sun3dvma.c | 3 +++
For m68k:
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterh
u bytes\n", __func__,
%zu, as sizeof() returns size_t.
Probably there are more. Yes, it's hard to get them right in all callers.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m6
On Wed, Jan 16, 2019 at 2:45 PM Mike Rapoport wrote:
> memblock_alloc() already clears the allocated memory, no point in doing it
> twice.
>
> Signed-off-by: Mike Rapoport
> arch/m68k/mm/mcfmmu.c | 1 -
For m68k part:
Acked-by: Geert Uytterhoeven
> --- a/arch/m68k/m
Signed-off-by: Geert Uytterhoeven
---
drivers/xen/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 90d387b50ab747f5..7f42d41f66ee98e3 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -86,7 +86,7 @@ config
g
Reviewed-by: Geert Uytterhoeven
> ---
> arch/m68k/emu/nfblock.c | 2 +-
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technic
On Mon, Jul 9, 2018 at 9:37 AM Geert Uytterhoeven wrote:
> JFYI, when comparing v4.18-rc4[1] to v4.18-rc3[3], the summaries are:
> - build errors: +17/-0
+ error: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko]
undefined!: => N/A
arm64-allmodconfig (__sync_icach
34 matches
Mail list logo
