from:"Geert Uytterhoeven"

Hi Krzysztof,

On Mon, Nov 13, 2023 at 1:22 PM Krzysztof Wilczyński  wrote:
> > > > Now, while you are looking at things, can you also take care about the 
> > > > following:
> > > >
> > > >   drivers/pci/controller/dwc/pcie-rcar-gen4.c:439:15: warning: cast to 
> > > > smaller integer type 'enum dw_pcie_device_mode'
> > > from 'const void *' [-Wvoid-pointer-to-enum-cast]
> >
> > Thank you for the report!
> >
> > > > This requires adding structs for each data member of the of_device_id 
> > > > type.
> > >
> > > That sounds like overkill to me.
> > > An intermediate cast to uintptr_t should fix the issue as well.
> >
> > I confirmed that the uintptr_t fixed the issue.
>
> We declined a similar fix in the past[1] ...
>
> > I also think that adding a new struct with the mode is overkill.
>
> ... with the hopes that a driver could drop the switch statements in place
> of using the other pattern.  Also, to be consistent with other drivers that
> do this already.

Note that the issue of casting is something we cannot fix easily:
some *_device_id structs use "kernel_ulong_t" for the "data" member,
others use "void *".

git grep -W "_device_id" -- include/linux/mod_devicetable.h | grep data

In addition, several drivers use multiple types of device IDs, so you
cannot settle on one type to avoid casts.

Also, putting enum values in instances of that struct, as suggested,
increases kernel size, for IMHO no additional gain.  If there is more
data to put in the struct, I agree it makes sense to use a struct.

> > So, I would like to fix the issue by using the cast of uintptr_t.
>
> Sure.  I appreciate that this would be more work.  When you send your
> patch, can you include an update to the iproc driver (and credit the
> original author from [1])?  I would appreciate it.
>
> 1. https://lore.kernel.org/linux-pci/20230814230008.GA196797@bhelgaas/

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'

Hi Christian,

On Sun, Nov 12, 2023 at 3:23 PM Christian Zigotzky
 wrote:
> On 07 November 2023 at 09:36 am, Christian Zigotzky wrote:
> > I have found out that fbdev no longer works with virtio-gpu-pci and
> > virtio-vga. It is not a problem with the penguin logos.
> >
> > Could you please check fbdev in QEMU virtual machines with
> > virtio-gpu-pci and virtio-vga graphics?
>
> > On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote:
> >> There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The
> >> penguins are not displayed at boot time)
> >>
> >> Error message:  [0.889302] virtio-pci :00:02.0: [drm] *ERROR*
> >> fbdev: Failed to setup generic emulation (ret=-2)
> >>
> >> The kernel 6.6 final doesn't have this issue.
> >>
> >> Please check the fbdev changes in the drm updates
> >> 'drm-next-2023-10-31-1'.

Thanks for your report!

I can confirm there is no graphics output with m68k/virt, and
bisected this to my own commit 6ae2ff23aa43a0c4 ("drm/client: Convert
drm_client_buffer_addfb() to drm_mode_addfb2()"), ouch...

It turns out the old call to drm_mode_addfb() caused a translation
from a fourcc to a bpp/depth pair to a _different_ fourcc, due to the
quirk processing in drm_driver_legacy_fb_format().
I.e. on m68k/virt, the original requested format was XR24, which was
translated to BX24. The former doesn't work, the latter works.

The following (gmail-whitespace-damaged) patch fixed the issue for me:

--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struct
drm_client_buffer *buffer,

fb_req.width = width;
fb_req.height = height;
+   if (client->dev->mode_config.quirk_addfb_prefer_host_byte_order) {
+   if (format == DRM_FORMAT_XRGB)
+   format = DRM_FORMAT_HOST_XRGB;
+   if (format == DRM_FORMAT_ARGB)
+   format = DRM_FORMAT_HOST_ARGB;
+   if (format == DRM_FORMAT_RGB565)
+   format = DRM_FORMAT_HOST_RGB565;
+   if (format == DRM_FORMAT_XRGB1555)
+   format = DRM_FORMAT_HOST_XRGB1555;
+   }
fb_req.pixel_format = format;
fb_req.handles[0] = handle;
fb_req.pitches[0] = buffer->pitch;

However, I don't think we want to sprinkle more of these
translations around... So perhaps we should (re)add a call to
drm_driver_legacy_fb_format() to drm_client_buffer_addfb()?

Second, as I doubt you are using a big-endian system, you are probably
running into a slightly different issue.

Oh wait, you did CC linuxppc-dev, so perhaps you are running on a
big-endian machine?

If not, please add

pr_info("%s: format = %p4cc\n", __func__, );

to drivers/gpu/drm/drm_client.c:drm_client_buffer_addfb(), and,
after reverting commit 6ae2ff23aa43a0c4, add

pr_info("%s: bpp %u/depth %u => r.pixel_format = %p4cc\n",
__func__, or->bpp, or->depth, _format);

to drivers/gpu/drm/drm_framebuffer.c:drm_mode_addfb(), so we know the
translation in your case?

Thanks!

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 0/3] PCI: dwc: Improve code readability

Hi Krzysztof,

On Mon, Nov 13, 2023 at 11:09 AM Krzysztof Wilczyński  wrote:
> > This patch series is based on the latest pci.git / next branch.
> [...]
>
> Thank you for following up to tidy things up!  Much appreciated.
>
> Now, while you are looking at things, can you also take care about the 
> following:
>
>   drivers/pci/controller/dwc/pcie-rcar-gen4.c:439:15: warning: cast to 
> smaller integer type 'enum dw_pcie_device_mode' from 'const void *' 
> [-Wvoid-pointer-to-enum-cast]
>
> This requires adding structs for each data member of the of_device_id type.

That sounds like overkill to me.
An intermediate cast to uintptr_t should fix the issue as well.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: Build regressions/improvements in v6.7-rc1


On Mon, 13 Nov 2023, Geert Uytterhoeven wrote:

Below is the list of build error/warning regressions/improvements in
v6.7-rc1[1] compared to v6.6[2].

Summarized:
 - build errors: +20/-7
 - build warnings: +24/-8

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/b85ea95d086471afb4ad062012a4d73cd328fa86/
 (238 out of 239 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/ffc253263a1375a65fa6c9f62a893e9767fbebfa/
 (all 239 configs)


*** ERRORS ***

20 error regressions:
 + /kisskb/src/include/linux/compiler_types.h: error: call to 
'__compiletime_assert_654' declared with attribute error: FIELD_PREP: value too 
large for the field:  => 435:38


powerpc-gcc5/powerpc-allyesconfig
drivers/edac/versal_edac.c: In function 'mc_probe':
num_chans = FIELD_PREP(XDDR_REG_CONFIG0_NUM_CHANS_MASK, regval);


 + {standard input}: Error: displacement to undefined symbol .L100 overflows 8-bit 
field :  => 588
 + {standard input}: Error: displacement to undefined symbol .L104 overflows 8-bit 
field :  => 588
 + {standard input}: Error: displacement to undefined symbol .L105 overflows 8-bit 
field :  => 593
 + {standard input}: Error: displacement to undefined symbol .L134 overflows 8-bit 
field :  => 598
 + {standard input}: Error: displacement to undefined symbol .L72 overflows 12-bit 
field:  => 589
 + {standard input}: Error: displacement to undefined symbol .L73 overflows 8-bit 
field :  => 580
 + {standard input}: Error: displacement to undefined symbol .L75 overflows 12-bit 
field:  => 586, 589, 606
 + {standard input}: Error: displacement to undefined symbol .L76 overflows 8-bit 
field :  => 577, 580
 + {standard input}: Error: displacement to undefined symbol .L77 overflows 8-bit 
field : 582 => 607, 585
 + {standard input}: Error: displacement to undefined symbol .L78 overflows 8-bit 
field :  => 610
 + {standard input}: Error: displacement to undefined symbol .L80 overflows 8-bit 
field :  => 607, 601
 + {standard input}: Error: displacement to undefined symbol .L81 overflows 8-bit 
field : 606 => 604, 610
 + {standard input}: Error: displacement to undefined symbol .L96 overflows 12-bit 
field:  => 602
 + {standard input}: Error: displacement to undefined symbol .L97 overflows 12-bit 
field:  => 607
 + {standard input}: Error: displacement to undefined symbol .L98 overflows 12-bit 
field:  => 602
 + {standard input}: Error: invalid operands for opcode:  => 612
 + {standard input}: Error: missing operand:  => 612
 + {standard input}: Error: pcrel too far: 601, 598, 604, 577, 595, 574 => 590, 
598, 599, 577, 596, 569, 604, 610, 572, 593
 + {standard input}: Error: unknown pseudo-op: `.l':  => 609


sh4-gcc1[123]/sh-all{mod,yes}config ICE

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] treewide: Spelling fix in comment

2023-10-20 Thread Geert Uytterhoeven

Hi Kunwu,

Thanks for your patch!

This is not a treewide change. Hence the oneline-summary should be
something prefixed by "[net-next] ps3_gelic"

On Fri, Oct 20, 2023 at 11:32 AM Kunwu Chan  wrote:
> reques -> request
>
> Fixes: 09dde54c6a69 ("PS3: gelic: Add wireless support for PS3")

No need for a Fixes tag for a spelling fix in a comment.

> Signed-off-by: Kunwu Chan 

Reviewed-by: Geert Uytterhoeven 

> --- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
> +++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
> @@ -1217,7 +1217,7 @@ static int gelic_wl_set_encodeext(struct net_device 
> *netdev,
> key_index = wl->current_key;
>
> if (!enc->length && (ext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)) {
> -   /* reques to change default key index */
> +   /* request to change default key index */
> pr_debug("%s: request to change default key to %d\n",
>  __func__, key_index);
>     wl->current_key = key_index;

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Geert Uytterhoeven

Hi Johannes,

On Thu, Oct 12, 2023 at 5:28 PM Johannes Berg  wrote:
> On Thu, 2023-10-12 at 16:36 +0200, Arnd Bergmann wrote:
> >
> > ps3-gelic-wireless
>
> Didn't Sony disable Linux on PS3 eventually? Though maybe someone still
> has some devices with old software.

If you didn't update the firmware, you could keep on using Linux.

And people may have found a vulnerability in more recent firmware
versions that allows them to run custom software.
I don't know, it's been +10 years ago I touched a PS3 ;-)

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

2023-10-12 Thread Geert Uytterhoeven

CC geoff, ppc

On Thu, Oct 12, 2023 at 4:46 PM Kalle Valo  wrote:
> "Arnd Bergmann"  writes:
>
> > On Thu, Oct 12, 2023, at 13:47, Kalle Valo wrote:
> >>
> >> Is anyone willing to submit patches? Use wireless-next as the baseline
> >> for patches and one driver per commit, please. That way it's easy to
> >> revert later, if needed (hopefully not).
> >
> > I can do it, I've already done most of the work for moving the
> > drivers, so I just need to split up my existing patch and leave out
> > the bits that get added to drivers/staging.
>
> Awesome, thank you!
>
> > I'll also send Greg a patch to remove rtl8192u now that we know
> > that this has been broken for 7 years. Similarly, I'd include
> > another patch to remove PCMCIA support for libertas, as that
> > would otherwise be the only remaining 16-bit PCMCIA wlan card,
> > and I could find no indication of this one ever being popular,
> > unlike the USB/SDIO/SPI variants of the same device or the
> > other PCMCIA drivers.
> >
> > This would leave only a handful of wext implementations in the
> > tree: ipw2x00, ps3-gelic-wireless, staging/rtl8712, staging/rtl8192e
> > and staging/ks7010. Since ipw2x00 is apparently still supported
> > in theory and was rather popular on Pentium-M based systems 20
> > years ago, this may still need to be converted to cfg80211
> > before you can remove support for wext style drivers altogether.
> > ps3-gelic-wireless and rtl8712 are also still maintained but have
> > a much smaller user base I assume.
>
> Actually I would prefer to remove ipw2x00 and ps3-gelic-wireless as
> well. I have not seen any evidence that there would be users for those
> drivers. If we find out that there really are users I can easily add the
> drivers back. The faster we get rid of wext the better, it really needs
> to go away.
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v3 1/9] vgacon: rework Kconfig dependencies

2023-10-10 Thread Geert Uytterhoeven

Hi Arnd,

On Mon, Oct 9, 2023 at 11:19 PM Arnd Bergmann  wrote:
> From: Arnd Bergmann 
>
> The list of dependencies here is phrased as an opt-out, but this is missing
> a lot of architectures that don't actually support VGA consoles, and some
> of the entries are stale:
>
>  - powerpc used to support VGA consoles in the old arch/ppc codebase, but
>the merged arch/powerpc never did
>
>  - arm lists footbridge, integrator and netwinder, but netwinder is actually
>part of footbridge, and integrator does not appear to have an actual
>VGA hardware, or list it in its ATAG or DT.
>
>  - mips has a few platforms (malta, sibyte, and sni) that initialize
>screen_info, on everything else the console is selected but cannot
>actually work.
>
>  - csky, hexgagon, loongarch, nios2, riscv and xtensa are not listed
>in the opt-out table and declare a screen_info to allow building
>vga_con, but this cannot work because the console is never selected.
>
> Replace this with an opt-in table that lists only the platforms that
> remain. This is effectively x86, plus a couple of historic workstation
> and server machines that reused parts of the x86 system architecture.
>
> Reviewed-by: Javier Martinez Canillas 
> Reviewed-by: Thomas Zimmermann 
> Reviewed-by: Khalid Aziz 
> Acked-by: Helge Deller 
> Signed-off-by: Arnd Bergmann 

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven 

A few suggestions for simplification below...

> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -7,9 +7,9 @@ menu "Console display driver support"
>
>  config VGA_CONSOLE
> bool "VGA text console" if EXPERT || !X86
> -   depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC &&  !SUPERH 
> && \
> -   (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || 
> ARCH_NETWINDER) && \
> -   !ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390 && !UML
> +   depends on ALPHA || IA64 || X86 || \
> +   (ARM && ARCH_FOOTBRIDGE) || \

You can drop "ARM &&", as it is implied by ARCH_FOOTBRIDGE.

> +   (MIPS && (MIPS_MALTA || SIBYTE_BCM112X || SIBYTE_SB1250 || 
> SIBYTE_BCM1x80 || SNI_RM))

Likewise for "MIPS &&".

The 3 SIBYTE dependencies can be replaced by SIBYTE_SB1xxx_SOC.

> select APERTURE_HELPERS if (DRM || FB || VFIO_PCI_CORE)
> default y
> help

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] arch: Reserve map_shadow_stack() syscall number for all architectures

2023-10-03 Thread Geert Uytterhoeven

On Thu, Sep 14, 2023 at 8:59 PM Sohil Mehta  wrote:
> commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall")
> recently added support for map_shadow_stack() but it is limited to x86
> only for now. There is a possibility that other architectures (namely,
> arm64 and RISC-V), that are implementing equivalent support for shadow
> stacks, might need to add support for it.
>
> Independent of that, reserving arch-specific syscall numbers in the
> syscall tables of all architectures is good practice and would help
> avoid future conflicts. map_shadow_stack() is marked as a conditional
> syscall in sys_ni.c. Adding it to the syscall tables of other
> architectures is harmless and would return ENOSYS when exercised.
>
> Note, map_shadow_stack() was assigned #453 during the merge process
> since #452 was taken by fchmodat2().
>
> For Powerpc, map it to sys_ni_syscall() as is the norm for Powerpc
> syscall tables.
>
> For Alpha, map_shadow_stack() takes up #563 as Alpha still diverges from
> the common syscall numbering system in the other architectures.
>
> Link: 
> https://lore.kernel.org/lkml/20230515212255.ga562...@debug.ba.rivosinc.com/
> Link: 
> https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b...@sirena.org.uk/
>
> Signed-off-by: Sohil Mehta 

>  arch/m68k/kernel/syscalls/syscall.tbl   | 1 +

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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig

2023-09-20 Thread Geert Uytterhoeven

Hi Peter,

On Tue, Sep 19, 2023 at 6:16 PM Peter Lafreniere  wrote:
> On Tue, Sep 19, 2023 at 12:02, Geert Uytterhoeven  
> wrote:
> > On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere pe...@n8pjl.ca wrote:
> > > 2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> > > Some hobbyist targets like m68k and alpha may prefer to keep all 
> > > filesystems
> > > available until total removal, but others like arm and UML have no need 
> > > for
> > > ReiserFS to be built unless specifically configured.
> >
> >
> > As UML is used a lot for testing, isn't it actually counter-productive
> > to remove ReiserFS from the UML defconfig? The less testing it
> > receives, the higher the chance of introducing regressions.
>
> UML is used for testing, but in my view that makes the inclusion of
> ReiserFS in its defconfig even worse. Users of UML are trying to test a

Why?
Because you want to avoid doing any testing at all on deprecated features?

> particular function, and so tend to use ext[2-4], as those are included in
> the defconfig and are well tested and stable. So there is no extra testing
> being done on ReiserFS due to its inclusion in the defconfig.

I'd expect global file system testers to use something along the line of:

for i in $(grep -v nodev /proc/filesystems ); do
echo --- Testing $i ---
dd if=/dev/zero of=testimage bs=1M count=1 seek=1
mkfs.$i testimage
mount testimage /mnt -t $i
[run xfstests on testimage]
rm -f testimage
done

> Keeping UML's defconfig as slim as possible improves build times, which is
> particularly important for kernel testing and development.

Good luck testing all functionality using a "slim" kernel ;-)

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig

2023-09-19 Thread Geert Uytterhoeven

Hi Peter,

On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere  wrote:
>  2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> Some hobbyist targets like m68k and alpha may prefer to keep all 
> filesystems
> available until total removal, but others like arm and UML have no need 
> for
> ReiserFS to be built unless specifically configured.

As UML is used a lot for testing, isn't it actually counter-productive
to remove ReiserFS from the UML defconfig?  The less testing it
receives, the higher the chance of introducing regressions.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX

2023-09-19 Thread Geert Uytterhoeven

Hi Michael,

On Tue, Sep 19, 2023 at 4:13 AM Michael Ellerman  wrote:
> Geert Uytterhoeven  writes:
> > Upstream Linux never had a "README.legal" file, but it was present
> > in early source releases of Linux/m68k.  It contained a simple copyright
> > notice and a link to a version of the "COPYING" file that predated the
> > addition of the "only valid GPL version is v2" clause.
> >
> > Get rid of the references to non-existent files by replacing the
> > boilerplate with SPDX license identifiers.
> >
> > Signed-off-by: Geert Uytterhoeven 
>
> LGTM.
>
> Acked-by: Michael Ellerman  (powerpc)

Can you please take it through the PPC tree?
Thanks!

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2 1/2] m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX

2023-09-18 Thread Geert Uytterhoeven

Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k.  It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.

Get rid of the references to non-existent files by replacing the
boilerplate with SPDX license identifiers.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Greg Ungerer 
---
v2:
  - Add Acked-by,
  - s/existant/existent/.
---
 arch/m68k/68000/entry.S | 7 ++-
 arch/m68k/bvme6000/config.c | 5 +
 arch/m68k/coldfire/entry.S  | 7 ++-
 arch/m68k/ifpsp060/Makefile | 6 ++
 arch/m68k/kernel/entry.S| 7 ++-
 arch/m68k/kernel/head.S | 8 ++--
 arch/m68k/mvme147/config.c  | 5 +
 arch/m68k/mvme16x/config.c  | 5 +
 arch/m68k/q40/config.c  | 5 +
 9 files changed, 14 insertions(+), 41 deletions(-)

diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S
index 7d63e2f1555a03dc..72e95663b62ffd54 100644
--- a/arch/m68k/68000/entry.S
+++ b/arch/m68k/68000/entry.S
@@ -1,12 +1,9 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  entry.S -- non-mmu 68000 interrupt and exception entry points
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  */
 
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index e604fe6602461334..8a2ee69a09f6659c 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  *  arch/m68k/bvme6000/config.c
  *
@@ -8,10 +9,6 @@
  *  linux/amiga/config.c
  *
  *  Copyright (C) 1993 Hamish Macdonald
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
  */
 
 #include 
diff --git a/arch/m68k/coldfire/entry.S b/arch/m68k/coldfire/entry.S
index 35104c5417ff4d07..4ea08336e2fb0aae 100644
--- a/arch/m68k/coldfire/entry.S
+++ b/arch/m68k/coldfire/entry.S
@@ -1,4 +1,5 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  entry.S  -- interrupt and exception processing for ColdFire
  *
  *  Copyright (C) 1999-2007, Greg Ungerer (g...@snapgear.com)
@@ -13,10 +14,6 @@
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  *
  * 68060 fixes by Jesper Skov
diff --git a/arch/m68k/ifpsp060/Makefile b/arch/m68k/ifpsp060/Makefile
index 56b530a96c2f33b5..00d0621f547ccb93 100644
--- a/arch/m68k/ifpsp060/Makefile
+++ b/arch/m68k/ifpsp060/Makefile
@@ -1,7 +1,5 @@
-# Makefile for 680x0 Linux 68060 integer/floating point support package
+# SPDX-License-Identifier: GPL-2.0-or-later
 #
-# This file is subject to the terms and conditions of the GNU General Public
-# License.  See the file "README.legal" in the main directory of this archive
-# for more details.
+# Makefile for 680x0 Linux 68060 integer/floating point support package
 
 obj-y := fskeleton.o iskeleton.o os.o
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 4dd2fd7acba9ea07..3bcdd32a6b36613d 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -1,13 +1,10 @@
-/* -*- mode: asm -*-
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ * -*- mode: asm -*-
  *
  *  linux/arch/m68k/kernel/entry.S
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  *
  * 68060 fixes by Jesper Skov
diff --git a/arch/m68k/kernel/head.S b/arch/m68k/kernel/head.S
index 9e812d8606be8301..852255cf60dec132 100644
--- a/arch/m68k/kernel/head.S
+++ b/arch/m68k/kernel/head.S
@@ -1,4 +1,5 @@
-/* -*- mode: asm -*-
+/* SPDX-License-Identifier: GPL-2.0-or-later
+** -*- mode: asm -*-
 **
 ** head.S -- This file contains the initial boot code for the
 **  Linux/68k kernel.
@@ -25,11 +26,6 @@
 **for linux-2.1.115
 ** 1999/02/11  Richard Zidlicky: added Q40 support (initial version 99/01/01)
 ** 2004/05/13 Kars de Jong: Finalised HP300 support
-**
-** This file is subject to the terms and conditions of the GNU General Public
-** License. See the file README.legal in the main directory of this archive
-** for more details.
-**
 */
 
 /*
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 7dfacd0b207a9750..8b5dc07f0811f2fc 100644
--- a/arch/m68k/mvme147/config.c

[PATCH v2 0/2] m68k/powerpc: Kill references to non-existent README.legal

2023-09-18 Thread Geert Uytterhoeven

Hi all,

Several source files contain license boilerplate that refers to the file
"README.legal", which never existed in upstream Linux. This is a relic
from the early port of Linux to the m68k processor family, before it was
merged in v1.3.94. Later, copies of this boilerplate ended up in the
PowerPC port.

The "README.legal" file (from e.g. [1]) read:

---8<-
Legal information about the Linux/68k software package

All files contained in this archive are copyrighted by one or more
person. They are not in the public domain.

Most of the files are copyrighted by Linus Torvalds, the original
writer of Linux for IBM PC clone systems. Some parts are copyrighted
by other IBM PC linux developers. Other parts are copyrighted by
Linux/68k developers.

This package is subject to the terms and conditions of the GNU General
Public License. A copy of this license may be found in the file named
"COPYING" which should be in the same directory as this file. If the
file has been omitted, you may obtain it by writing to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
->8---

Note that the "COPYING" file at that time corresponded to the version
from upstream Linux v0.99.11 until v2.1.104, and thus predated the
addition of the "only valid GPL version is v2" clause in v2.4.0-test8.

This patch series gets rid of the references to README.legal by
replacing the boilerplate with SPDX license identifiers.

Changes compared to v1[2]:
- Add Acked-by,
- s/existant/existent/.

Thanks for your comments!

[1]
https://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/680x0/v0.9/linux-0.9.tar.gz
[2] "[PATCH 0/2] m68k/powerpc: Kill references to non-existent README.legal
https://lore.kernel.org/r/cover.1694095086.git.ge...@linux-m68k.org

Geert Uytterhoeven (2):
m68k: Replace GPL 2.0+ README.legal boilerplate with SPDX
powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX

--
2.34.1

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate with SPDX

2023-09-18 Thread Geert Uytterhoeven

Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k.  It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.

Get rid of the references to non-existent files by replacing the
boilerplate with SPDX license identifiers.

Signed-off-by: Geert Uytterhoeven 
---
v2:
  - s/existant/existent/.
---
 arch/powerpc/kernel/ptrace/ptrace.c | 5 +
 arch/powerpc/kernel/signal.c| 5 +
 arch/powerpc/kernel/signal.h| 7 ++-
 3 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/kernel/ptrace/ptrace.c 
b/arch/powerpc/kernel/ptrace/ptrace.c
index 5d7a72b41ae71158..727ed4a145451356 100644
--- a/arch/powerpc/kernel/ptrace/ptrace.c
+++ b/arch/powerpc/kernel/ptrace/ptrace.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  *  PowerPC version
  *Copyright (C) 1995-1996 Gary Thomas (g...@linuxppc.org)
@@ -9,10 +10,6 @@
  *
  * Modified by Cort Dougan (c...@hq.fsmlabs.com)
  * and Paul Mackerras (pau...@samba.org).
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #include 
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index 68a91e553e14cea2..aa17e62f37547a79 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  * Common signal handling code for both 32 and 64 bits
  *
  *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation
  *Extracted from signal_32.c and signal_64.c
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #include 
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index a429c57ed4331805..58ecea1cdc27ae80 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -1,10 +1,7 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation
  *Extracted from signal_32.c and signal_64.c
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #ifndef _POWERPC_ARCH_SIGNAL_H
-- 
2.34.1

Re: [PATCH v4 2/5] fbdev: Replace fb_pgprotect() with pgprot_framebuffer()

2023-09-13 Thread Geert Uytterhoeven

Hi Thomas,

On Tue, Sep 12, 2023 at 5:32 PM Thomas Zimmermann  wrote:
> Rename the fbdev mmap helper fb_pgprotect() to pgprot_framebuffer(
> The helper sets VMA page-access flags for framebuffers in device I/O
> memory.
>
> Also clean up the helper's parameters and return value. Instead of
> the VMA instance, pass the individial parameters separately: existing
> page-access flags, the VMAs start and end addresses and the offset
> in the underlying device memory rsp file. Return the new page-access
> flags. These changes align pgprot_framebuffer() with other pgprot_()
> functions.
>
> v4:
> * fix commit message (Christophe)
> v3:
> * rename fb_pgprotect() to pgprot_framebuffer() (Arnd)
>
> Signed-off-by: Thomas Zimmermann 

Thanks for your patch!

>  arch/m68k/include/asm/fb.h   | 19 ++-----

Looks like you forgot to apply my
Acked-by: Geert Uytterhoeven 
given on v1.

I didn't notice before, as I never received v2 and v3 due to the
gmail/vger email issues.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 0/2] m68k/powerpc: Kill references to non-existent README.legal

Hi Christophe,

On Thu, Sep 7, 2023 at 4:25 PM Christophe Leroy
 wrote:
> Le 07/09/2023 à 16:21, Geert Uytterhoeven a écrit :
> > Several source files contain license boilerplate that refers to the file
> > "README.legal", which never existed in upstream Linux.  This is a relic
> > from the early port of Linux to the m68k processor family, before it was
> > merged in v1.3.94.  Later, copies of this boilerplate ended up in the
> > PowerPC port.
> >
> > The "README.legal" file (from e.g. [1]) read:
> >
> > ---8<-
> > Legal information about the Linux/68k software package
> >
> > All files contained in this archive are copyrighted by one or more
> > person.  They are not in the public domain.
> >
> > Most of the files are copyrighted by Linus Torvalds, the original
> > writer of Linux for IBM PC clone systems.  Some parts are copyrighted
> > by other IBM PC linux developers.  Other parts are copyrighted by
> > Linux/68k developers.
> >
> > This package is subject to the terms and conditions of the GNU General
> > Public License.  A copy of this license may be found in the file named
> > "COPYING" which should be in the same directory as this file.  If the
> > file has been omitted, you may obtain it by writing to the Free
> > Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> > ->8---
> >
> > Note that the "COPYING" file at that time corresponded to the version
> > from upstream Linux v0.99.11 until v2.1.104, and thus predated the
> > addition of the "only valid GPL version is v2" clause in v2.4.0-test8.
> >
> > This patch series gets rid of the references to README.legal by
> > replacing the boilerplate with SPDX license identifiers.
> >
> > Thanks for your comments!
>
> As far as I know this kind of patch has to be copied to
> linux-s...@vger.kernel.org

Thanks, added to CC.

> > [1] 
> > https://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/680x0/v0.9/linux-0.9.tar.gz
> >
> > Geert Uytterhoeven (2):
> >m68k: Replace GPL 2.0+ README.legal boilerplate by SPDX
> >powerpc: Replace GPL 2.0+ README.legal boilerplate by SPDX
> >
> >   arch/m68k/68000/entry.S | 7 ++-
> >   arch/m68k/bvme6000/config.c | 5 +
> >   arch/m68k/coldfire/entry.S  | 7 ++-
> >   arch/m68k/ifpsp060/Makefile | 6 ++
> >   arch/m68k/kernel/entry.S| 7 ++-
> >   arch/m68k/kernel/head.S | 8 ++--
> >   arch/m68k/mvme147/config.c  | 5 +
> >   arch/m68k/mvme16x/config.c  | 5 +
> >   arch/m68k/q40/config.c  | 5 +
> >   arch/powerpc/kernel/ptrace/ptrace.c | 5 +
> >   arch/powerpc/kernel/signal.c| 5 +
> >   arch/powerpc/kernel/signal.h| 7 ++-
> >   12 files changed, 18 insertions(+), 54 deletions(-)

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 1/2] m68k: Replace GPL 2.0+ README.legal boilerplate by SPDX

Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k.  It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.

Get rid of the references to non-existant files by replacing the
boilerplate with SPDX license identifiers.

Signed-off-by: Geert Uytterhoeven 
---
 arch/m68k/68000/entry.S | 7 ++-
 arch/m68k/bvme6000/config.c | 5 +
 arch/m68k/coldfire/entry.S  | 7 ++-
 arch/m68k/ifpsp060/Makefile | 6 ++
 arch/m68k/kernel/entry.S| 7 ++-
 arch/m68k/kernel/head.S | 8 ++--
 arch/m68k/mvme147/config.c  | 5 +
 arch/m68k/mvme16x/config.c  | 5 +
 arch/m68k/q40/config.c  | 5 +
 9 files changed, 14 insertions(+), 41 deletions(-)

diff --git a/arch/m68k/68000/entry.S b/arch/m68k/68000/entry.S
index 7d63e2f1555a03dc..72e95663b62ffd54 100644
--- a/arch/m68k/68000/entry.S
+++ b/arch/m68k/68000/entry.S
@@ -1,12 +1,9 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  entry.S -- non-mmu 68000 interrupt and exception entry points
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  */
 
diff --git a/arch/m68k/bvme6000/config.c b/arch/m68k/bvme6000/config.c
index e604fe6602461334..8a2ee69a09f6659c 100644
--- a/arch/m68k/bvme6000/config.c
+++ b/arch/m68k/bvme6000/config.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  *  arch/m68k/bvme6000/config.c
  *
@@ -8,10 +9,6 @@
  *  linux/amiga/config.c
  *
  *  Copyright (C) 1993 Hamish Macdonald
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
  */
 
 #include 
diff --git a/arch/m68k/coldfire/entry.S b/arch/m68k/coldfire/entry.S
index 35104c5417ff4d07..4ea08336e2fb0aae 100644
--- a/arch/m68k/coldfire/entry.S
+++ b/arch/m68k/coldfire/entry.S
@@ -1,4 +1,5 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *  entry.S  -- interrupt and exception processing for ColdFire
  *
  *  Copyright (C) 1999-2007, Greg Ungerer (g...@snapgear.com)
@@ -13,10 +14,6 @@
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  *
  * 68060 fixes by Jesper Skov
diff --git a/arch/m68k/ifpsp060/Makefile b/arch/m68k/ifpsp060/Makefile
index 56b530a96c2f33b5..00d0621f547ccb93 100644
--- a/arch/m68k/ifpsp060/Makefile
+++ b/arch/m68k/ifpsp060/Makefile
@@ -1,7 +1,5 @@
-# Makefile for 680x0 Linux 68060 integer/floating point support package
+# SPDX-License-Identifier: GPL-2.0-or-later
 #
-# This file is subject to the terms and conditions of the GNU General Public
-# License.  See the file "README.legal" in the main directory of this archive
-# for more details.
+# Makefile for 680x0 Linux 68060 integer/floating point support package
 
 obj-y := fskeleton.o iskeleton.o os.o
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index 4dd2fd7acba9ea07..3bcdd32a6b36613d 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -1,13 +1,10 @@
-/* -*- mode: asm -*-
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ * -*- mode: asm -*-
  *
  *  linux/arch/m68k/kernel/entry.S
  *
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file README.legal in the main directory of this archive
- * for more details.
- *
  * Linux/m68k support by Hamish Macdonald
  *
  * 68060 fixes by Jesper Skov
diff --git a/arch/m68k/kernel/head.S b/arch/m68k/kernel/head.S
index 9e812d8606be8301..852255cf60dec132 100644
--- a/arch/m68k/kernel/head.S
+++ b/arch/m68k/kernel/head.S
@@ -1,4 +1,5 @@
-/* -*- mode: asm -*-
+/* SPDX-License-Identifier: GPL-2.0-or-later
+** -*- mode: asm -*-
 **
 ** head.S -- This file contains the initial boot code for the
 **  Linux/68k kernel.
@@ -25,11 +26,6 @@
 **for linux-2.1.115
 ** 1999/02/11  Richard Zidlicky: added Q40 support (initial version 99/01/01)
 ** 2004/05/13 Kars de Jong: Finalised HP300 support
-**
-** This file is subject to the terms and conditions of the GNU General Public
-** License. See the file README.legal in the main directory of this archive
-** for more details.
-**
 */
 
 /*
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 7dfacd0b207a9750..8b5dc07f0811f2fc 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identif

[PATCH 2/2] powerpc: Replace GPL 2.0+ README.legal boilerplate by SPDX

Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k.  It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.

Get rid of the references to non-existant files by replacing the
boilerplate with SPDX license identifiers.

Signed-off-by: Geert Uytterhoeven 
---
 arch/powerpc/kernel/ptrace/ptrace.c | 5 +
 arch/powerpc/kernel/signal.c| 5 +
 arch/powerpc/kernel/signal.h| 7 ++-
 3 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/kernel/ptrace/ptrace.c 
b/arch/powerpc/kernel/ptrace/ptrace.c
index 5d7a72b41ae71158..727ed4a145451356 100644
--- a/arch/powerpc/kernel/ptrace/ptrace.c
+++ b/arch/powerpc/kernel/ptrace/ptrace.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  *  PowerPC version
  *Copyright (C) 1995-1996 Gary Thomas (g...@linuxppc.org)
@@ -9,10 +10,6 @@
  *
  * Modified by Cort Dougan (c...@hq.fsmlabs.com)
  * and Paul Mackerras (pau...@samba.org).
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #include 
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index 68a91e553e14cea2..aa17e62f37547a79 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
 /*
  * Common signal handling code for both 32 and 64 bits
  *
  *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation
  *Extracted from signal_32.c and signal_64.c
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #include 
diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index a429c57ed4331805..58ecea1cdc27ae80 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -1,10 +1,7 @@
-/*
+/* SPDX-License-Identifier: GPL-2.0-or-later
+ *
  *Copyright (c) 2007 Benjamin Herrenschmidt, IBM Corporation
  *Extracted from signal_32.c and signal_64.c
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License.  See the file README.legal in the main directory of
- * this archive for more details.
  */
 
 #ifndef _POWERPC_ARCH_SIGNAL_H
-- 
2.34.1

[PATCH 0/2] m68k/powerpc: Kill references to non-existent README.legal

Hi all,

The "README.legal" file (from e.g. [1]) read:

---8<-
Legal information about the Linux/68k software package

All files contained in this archive are copyrighted by one or more
person. They are not in the public domain.

This patch series gets rid of the references to README.legal by
replacing the boilerplate with SPDX license identifiers.

Thanks for your comments!

[1]
https://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/680x0/v0.9/linux-0.9.tar.gz

Geert Uytterhoeven (2):
m68k: Replace GPL 2.0+ README.legal boilerplate by SPDX
powerpc: Replace GPL 2.0+ README.legal boilerplate by SPDX

--
2.34.1

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/4] fbdev: Replace fb_pgprotect() with fb_pgprot_device()

2023-09-04 Thread Geert Uytterhoeven

On Sat, Sep 2, 2023 at 11:13 AM Thomas Zimmermann  wrote:
> Rename the fbdev mmap helper fb_pgprotect() to fb_pgprot_device().
> The helper sets VMA page-access flags for framebuffers in device I/O
> memory. The new name follows pgprot_device(), which does the same for
> arbitrary devices.
>
> Also clean up the helper's parameters and return value. Instead of
> the VMA instance, pass the individial parameters separately: existing
> page-access flags, the VMAs start and end addresses and the offset
> in the underlying device memory rsp file. Return the new page-access
> flags. These changes align fb_pgprot_device() closer with pgprot_device.
>
> Signed-off-by: Thomas Zimmermann 

>  arch/m68k/include/asm/fb.h   | 19 ++-

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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: (subset) [PATCH 00/17] -Wmissing-prototype warning fixes

2023-08-28 Thread Geert Uytterhoeven

On Sat, Aug 26, 2023 at 12:44 AM Michael Schmitz  wrote:
> (Incidentally - did you ever publish the m68k full history tree anywhere
> in git?)

You mean the gitified version of the Linux/m68k CVS tree Ralf created
for me because my machine wasn't powerful enough?
No, and I should look into doing that...

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: (subset) [PATCH 00/17] -Wmissing-prototype warning fixes

2023-08-25 Thread Geert Uytterhoeven

Hi Michael,

On Fri, Aug 25, 2023 at 3:31 AM Michael Schmitz  wrote:
> On 25/08/23 13:12, Martin K. Petersen wrote:
> > [11/17] scsi: gvp11: remove unused gvp11_setup() function
> >  https://git.kernel.org/mkp/scsi/c/bfaa4a0ce1bb
>
> I somehow missed that one ...
>
> The gvp11_setup() function was probably a relic from the times before
> module parameters.
>
> Since gvp11_xfer_mask appears to be required for some Amiga systems to
> set the DMA mask, I'd best send a patch to add such a module parameter ...
>
> Do you know any details around the use of DMA masks for Amiga WD33C93
> drivers, Geert?

Doh, it's been a while, and I never had an affected system.
Probably it's needed on A2000 with an accelerator card and GVP II SCSI,
to prevent DMA to RAM banks that do not support fast DMA cycles.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 9/9] m68k: Remove

There are no more users of .

Signed-off-by: Geert Uytterhoeven 
---
 arch/m68k/include/asm/ide.h | 67 -
 1 file changed, 67 deletions(-)
 delete mode 100644 arch/m68k/include/asm/ide.h

diff --git a/arch/m68k/include/asm/ide.h b/arch/m68k/include/asm/ide.h
deleted file mode 100644
index 05cc7dc00e0c1437..
--- a/arch/m68k/include/asm/ide.h
+++ /dev/null
@@ -1,67 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- *  Copyright (C) 1994-1996  Linus Torvalds & authors
- */
-
-/* Copyright(c) 1996 Kars de Jong */
-/* Based on the ide driver from 1.2.13pl8 */
-
-/*
- * Credits (alphabetical):
- *
- *  - Bjoern Brauel
- *  - Kars de Jong
- *  - Torsten Ebeling
- *  - Dwight Engen
- *  - Thorsten Floeck
- *  - Roman Hodek
- *  - Guenther Kelleter
- *  - Chris Lawrence
- *  - Michael Rausch
- *  - Christian Sauer
- *  - Michael Schmitz
- *  - Jes Soerensen
- *  - Michael Thurm
- *  - Geert Uytterhoeven
- */
-
-#ifndef _M68K_IDE_H
-#define _M68K_IDE_H
-
-#ifdef __KERNEL__
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_MMU
-
-/*
- * Get rid of defs from io.h - ide has its private and conflicting versions
- * Since so far no single m68k platform uses ISA/PCI I/O space for IDE, we
- * always use the `raw' MMIO versions
- */
-#undef readb
-#undef readw
-#undef writeb
-#undef writew
-
-#define readb  in_8
-#define readw  in_be16
-#define __ide_mm_insw(port, addr, n)   raw_insw((u16 *)port, addr, n)
-#define __ide_mm_insl(port, addr, n)   raw_insl((u32 *)port, addr, n)
-#define writeb(val, port)  out_8(port, val)
-#define writew(val, port)  out_be16(port, val)
-#define __ide_mm_outsw(port, addr, n)  raw_outsw((u16 *)port, addr, n)
-#define __ide_mm_outsl(port, addr, n)  raw_outsl((u32 *)port, addr, n)
-
-#else
-
-#define __ide_mm_insw(port, addr, n)   io_insw((unsigned int)port, addr, n)
-#define __ide_mm_insl(port, addr, n)   io_insl((unsigned int)port, addr, n)
-#define __ide_mm_outsw(port, addr, n)  io_outsw((unsigned int)port, addr, n)
-#define __ide_mm_outsl(port, addr, n)  io_outsl((unsigned int)port, addr, n)
-
-#endif /* CONFIG_MMU */
-
-#endif /* __KERNEL__ */
-#endif /* _M68K_IDE_H */
-- 
2.34.1

[PATCH 6/9] ata: pata_buddha: Remove #include

The Buddha, Catweasel, and X-Surf PATA driver does not need anything
from .

Signed-off-by: Geert Uytterhoeven 
---
 drivers/ata/pata_buddha.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/pata_buddha.c b/drivers/ata/pata_buddha.c
index 49bc619b83e255a3..c36ee991d5e5fdcc 100644
--- a/drivers/ata/pata_buddha.c
+++ b/drivers/ata/pata_buddha.c
@@ -27,7 +27,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "pata_buddha"
-- 
2.34.1

[PATCH treewide 0/9] Remove obsolete IDE headers

Hi all,

This patch series removes all unused  headers and
.   was still included by 3 PATA
drivers for m68k platforms, but without any real need.

The first 5 patches have no dependencies.
The last patch depends on the 3 pata patches.

Thanks for your comments!

Geert Uytterhoeven (9):
  ARM: Remove 
  parisc: Remove 
  powerpc: Remove 
  sparc: Remove 
  asm-generic: Remove ide_iops.h
  ata: pata_buddha: Remove #include 
  ata: pata_falcon: Remove #include 
  ata: pata_gayle: Remove #include 
  m68k: Remove 

 arch/arm/include/asm/ide.h | 24 -
 arch/m68k/include/asm/ide.h| 67 ---
 arch/parisc/include/asm/ide.h  | 54 ---
 arch/powerpc/include/asm/ide.h | 18 ---
 arch/sparc/include/asm/ide.h   | 97 --
 drivers/ata/pata_buddha.c  |  1 -
 drivers/ata/pata_falcon.c  |  1 -
 drivers/ata/pata_gayle.c   |  1 -
 include/asm-generic/ide_iops.h | 39 --
 9 files changed, 302 deletions(-)
 delete mode 100644 arch/arm/include/asm/ide.h
 delete mode 100644 arch/m68k/include/asm/ide.h
 delete mode 100644 arch/parisc/include/asm/ide.h
 delete mode 100644 arch/powerpc/include/asm/ide.h
 delete mode 100644 arch/sparc/include/asm/ide.h
 delete mode 100644 include/asm-generic/ide_iops.h

-- 
2.34.1

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 2/9] parisc: Remove

As of commit b7fb14d3ac63117e ("ide: remove the legacy ide driver") in
v5.14, there are no more generic users of .

Signed-off-by: Geert Uytterhoeven 
---
 arch/parisc/include/asm/ide.h | 54 ---
 1 file changed, 54 deletions(-)
 delete mode 100644 arch/parisc/include/asm/ide.h

diff --git a/arch/parisc/include/asm/ide.h b/arch/parisc/include/asm/ide.h
deleted file mode 100644
index 7aa75b93a1b6c76d..
--- a/arch/parisc/include/asm/ide.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- *  linux/include/asm-parisc/ide.h
- *
- *  Copyright (C) 1994-1996  Linus Torvalds & authors
- */
-
-/*
- *  This file contains the PARISC architecture specific IDE code.
- */
-
-#ifndef __ASM_PARISC_IDE_H
-#define __ASM_PARISC_IDE_H
-
-/* Generic I/O and MEMIO string operations.  */
-
-#define __ide_insw insw
-#define __ide_insl insl
-#define __ide_outswoutsw
-#define __ide_outsloutsl
-
-static __inline__ void __ide_mm_insw(void __iomem *port, void *addr, u32 count)
-{
-   while (count--) {
-   *(u16 *)addr = __raw_readw(port);
-   addr += 2;
-   }
-}
-
-static __inline__ void __ide_mm_insl(void __iomem *port, void *addr, u32 count)
-{
-   while (count--) {
-   *(u32 *)addr = __raw_readl(port);
-   addr += 4;
-   }
-}
-
-static __inline__ void __ide_mm_outsw(void __iomem *port, void *addr, u32 
count)
-{
-   while (count--) {
-   __raw_writew(*(u16 *)addr, port);
-   addr += 2;
-   }
-}
-
-static __inline__ void __ide_mm_outsl(void __iomem *port, void *addr, u32 
count)
-{
-   while (count--) {
-   __raw_writel(*(u32 *)addr, port);
-   addr += 4;
-   }
-}
-
-#endif /* __ASM_PARISC_IDE_H */
-- 
2.34.1

[PATCH 4/9] sparc: Remove

As of commit b7fb14d3ac63117e ("ide: remove the legacy ide driver") in
v5.14, there are no more generic users of .

Signed-off-by: Geert Uytterhoeven 
---
 arch/sparc/include/asm/ide.h | 97 
 1 file changed, 97 deletions(-)
 delete mode 100644 arch/sparc/include/asm/ide.h

diff --git a/arch/sparc/include/asm/ide.h b/arch/sparc/include/asm/ide.h
deleted file mode 100644
index 904cc6cbc1550cd8..
--- a/arch/sparc/include/asm/ide.h
+++ /dev/null
@@ -1,97 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* ide.h: SPARC PCI specific IDE glue.
- *
- * Copyright (C) 1997  David S. Miller (da...@davemloft.net)
- * Copyright (C) 1998  Eddie C. Dost   (e...@skynet.be)
- * Adaptation from sparc64 version to sparc by Pete Zaitcev.
- */
-
-#ifndef _SPARC_IDE_H
-#define _SPARC_IDE_H
-
-#ifdef __KERNEL__
-
-#include 
-#ifdef CONFIG_SPARC64
-#include 
-#include 
-#include 
-#else
-#include 
-#include 
-#endif
-
-#define __ide_insl(data_reg, buffer, wcount) \
-   __ide_insw(data_reg, buffer, (wcount)<<1)
-#define __ide_outsl(data_reg, buffer, wcount) \
-   __ide_outsw(data_reg, buffer, (wcount)<<1)
-
-/* On sparc, I/O ports and MMIO registers are accessed identically.  */
-#define __ide_mm_insw  __ide_insw
-#define __ide_mm_insl  __ide_insl
-#define __ide_mm_outsw __ide_outsw
-#define __ide_mm_outsl __ide_outsl
-
-static inline void __ide_insw(void __iomem *port, void *dst, u32 count)
-{
-#if defined(CONFIG_SPARC64) && defined(DCACHE_ALIASING_POSSIBLE)
-   unsigned long end = (unsigned long)dst + (count << 1);
-#endif
-   u16 *ps = dst;
-   u32 *pi;
-
-   if(((unsigned long)ps) & 0x2) {
-   *ps++ = __raw_readw(port);
-   count--;
-   }
-   pi = (u32 *)ps;
-   while(count >= 2) {
-   u32 w;
-
-   w  = __raw_readw(port) << 16;
-   w |= __raw_readw(port);
-   *pi++ = w;
-   count -= 2;
-   }
-   ps = (u16 *)pi;
-   if(count)
-   *ps++ = __raw_readw(port);
-
-#if defined(CONFIG_SPARC64) && defined(DCACHE_ALIASING_POSSIBLE)
-   __flush_dcache_range((unsigned long)dst, end);
-#endif
-}
-
-static inline void __ide_outsw(void __iomem *port, const void *src, u32 count)
-{
-#if defined(CONFIG_SPARC64) && defined(DCACHE_ALIASING_POSSIBLE)
-   unsigned long end = (unsigned long)src + (count << 1);
-#endif
-   const u16 *ps = src;
-   const u32 *pi;
-
-   if(((unsigned long)src) & 0x2) {
-   __raw_writew(*ps++, port);
-   count--;
-   }
-   pi = (const u32 *)ps;
-   while(count >= 2) {
-   u32 w;
-
-   w = *pi++;
-   __raw_writew((w >> 16), port);
-   __raw_writew(w, port);
-   count -= 2;
-   }
-   ps = (const u16 *)pi;
-   if(count)
-   __raw_writew(*ps, port);
-
-#if defined(CONFIG_SPARC64) && defined(DCACHE_ALIASING_POSSIBLE)
-   __flush_dcache_range((unsigned long)src, end);
-#endif
-}
-
-#endif /* __KERNEL__ */
-
-#endif /* _SPARC_IDE_H */
-- 
2.34.1

[PATCH 1/9] ARM: Remove

As of commit b7fb14d3ac63117e ("ide: remove the legacy ide driver") in
v5.14, there are no more generic users of .

Signed-off-by: Geert Uytterhoeven 
---
 arch/arm/include/asm/ide.h | 24 
 1 file changed, 24 deletions(-)
 delete mode 100644 arch/arm/include/asm/ide.h

diff --git a/arch/arm/include/asm/ide.h b/arch/arm/include/asm/ide.h
deleted file mode 100644
index a81e0b0d6747aa2f..
--- a/arch/arm/include/asm/ide.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- *  arch/arm/include/asm/ide.h
- *
- *  Copyright (C) 1994-1996  Linus Torvalds & authors
- */
-
-/*
- *  This file contains the ARM architecture specific IDE code.
- */
-
-#ifndef __ASMARM_IDE_H
-#define __ASMARM_IDE_H
-
-#ifdef __KERNEL__
-
-#define __ide_mm_insw(port,addr,len)   readsw(port,addr,len)
-#define __ide_mm_insl(port,addr,len)   readsl(port,addr,len)
-#define __ide_mm_outsw(port,addr,len)  writesw(port,addr,len)
-#define __ide_mm_outsl(port,addr,len)  writesl(port,addr,len)
-
-#endif /* __KERNEL__ */
-
-#endif /* __ASMARM_IDE_H */
-- 
2.34.1

[PATCH 5/9] asm-generic: Remove ide_iops.h

The last user of ide_iops.h was removed in commit b7fb14d3ac63117e
("ide: remove the legacy ide driver") in v5.14.

Signed-off-by: Geert Uytterhoeven 
---
 include/asm-generic/ide_iops.h | 39 --
 1 file changed, 39 deletions(-)
 delete mode 100644 include/asm-generic/ide_iops.h

diff --git a/include/asm-generic/ide_iops.h b/include/asm-generic/ide_iops.h
deleted file mode 100644
index 81dfa3ee5e0697b7..
--- a/include/asm-generic/ide_iops.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/* Generic I/O and MEMIO string operations.  */
-
-#define __ide_insw insw
-#define __ide_insl insl
-#define __ide_outswoutsw
-#define __ide_outsloutsl
-
-static __inline__ void __ide_mm_insw(void __iomem *port, void *addr, u32 count)
-{
-   while (count--) {
-   *(u16 *)addr = readw(port);
-   addr += 2;
-   }
-}
-
-static __inline__ void __ide_mm_insl(void __iomem *port, void *addr, u32 count)
-{
-   while (count--) {
-   *(u32 *)addr = readl(port);
-   addr += 4;
-   }
-}
-
-static __inline__ void __ide_mm_outsw(void __iomem *port, void *addr, u32 
count)
-{
-   while (count--) {
-   writew(*(u16 *)addr, port);
-   addr += 2;
-   }
-}
-
-static __inline__ void __ide_mm_outsl(void __iomem * port, void *addr, u32 
count)
-{
-   while (count--) {
-   writel(*(u32 *)addr, port);
-   addr += 4;
-   }
-}
-- 
2.34.1

[PATCH 3/9] powerpc: Remove

As of commit b7fb14d3ac63117e ("ide: remove the legacy ide driver") in
v5.14, there are no more generic users of .

Signed-off-by: Geert Uytterhoeven 
---
 arch/powerpc/include/asm/ide.h | 18 --
 1 file changed, 18 deletions(-)
 delete mode 100644 arch/powerpc/include/asm/ide.h

diff --git a/arch/powerpc/include/asm/ide.h b/arch/powerpc/include/asm/ide.h
deleted file mode 100644
index ce87a4441ca34887..
--- a/arch/powerpc/include/asm/ide.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- *  Copyright (C) 1994-1996 Linus Torvalds & authors
- *
- *  This file contains the powerpc architecture specific IDE code.
- */
-#ifndef _ASM_POWERPC_IDE_H
-#define _ASM_POWERPC_IDE_H
-
-#include 
-#include 
-
-#define __ide_mm_insw(p, a, c) readsw((void __iomem *)(p), (a), (c))
-#define __ide_mm_insl(p, a, c) readsl((void __iomem *)(p), (a), (c))
-#define __ide_mm_outsw(p, a, c)writesw((void __iomem *)(p), (a), (c))
-#define __ide_mm_outsl(p, a, c)writesl((void __iomem *)(p), (a), (c))
-
-#endif /* _ASM_POWERPC_IDE_H */
-- 
2.34.1

[PATCH 8/9] ata: pata_gayle: Remove #include

The Amiga Gayle PATA driver does not need anything from .

Signed-off-by: Geert Uytterhoeven 
---
 drivers/ata/pata_gayle.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/pata_gayle.c b/drivers/ata/pata_gayle.c
index e5aa07f92106547e..3bdbe2b65a2b49f1 100644
--- a/drivers/ata/pata_gayle.c
+++ b/drivers/ata/pata_gayle.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define DRV_NAME "pata_gayle"
-- 
2.34.1

[PATCH 7/9] ata: pata_falcon: Remove #include

The Atari Falcon PATA driver does not need anything from .

Signed-off-by: Geert Uytterhoeven 
---
 drivers/ata/pata_falcon.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/pata_falcon.c b/drivers/ata/pata_falcon.c
index 996516e64f13504e..0904232e5e0c4c8c 100644
--- a/drivers/ata/pata_falcon.c
+++ b/drivers/ata/pata_falcon.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define DRV_NAME "pata_falcon"
 #define DRV_VERSION "0.1.0"
-- 
2.34.1

Re: [PATCH] treewide: drop CONFIG_EMBEDDED

2023-08-16 Thread Geert Uytterhoeven

Hi Randy,

On Wed, Aug 16, 2023 at 7:50 AM Randy Dunlap  wrote:
> There is only one Kconfig user of CONFIG_EMBEDDED and it can be
> switched to EXPERT or "if !ARCH_MULTIPLATFORM" (suggested by Arnd).
>
> Signed-off-by: Randy Dunlap 

Makes perfect sense to me.

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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] syscalls: Cleanup references to sys_lookup_dcookie()

2023-07-25 Thread Geert Uytterhoeven

On Mon, Jul 10, 2023 at 8:52 PM Sohil Mehta  wrote:
> commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
> syscall definition for lookup_dcookie.  However, syscall tables still
> point to the old sys_lookup_dcookie() definition. Update syscall tables
> of all architectures to directly point to sys_ni_syscall() instead.
>
> Signed-off-by: Sohil Mehta 
> Reviewed-by: Randy Dunlap 
> Acked-by: Namhyung Kim  # for perf
> ---
> v2:
> - Rebased to v6.5-rc1. No other dependencies.
> - Added acquired tags.

>  arch/m68k/kernel/syscalls/syscall.tbl   | 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 technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 3/5] arch: Register fchmodat2, usually as syscall 452

2023-07-25 Thread Geert Uytterhoeven

On Tue, Jul 11, 2023 at 6:25 PM Alexey Gladkov  wrote:
> From: Palmer Dabbelt 
>
> This registers the new fchmodat2 syscall in most places as nuber 452,
> with alpha being the exception where it's 562.  I found all these sites
> by grepping for fspick, which I assume has found me everything.
>
> Signed-off-by: Palmer Dabbelt 
> Signed-off-by: Alexey Gladkov 

>  arch/m68k/kernel/syscalls/syscall.tbl   | 1 +

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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 1/9] vgacon: rework Kconfig dependencies

2023-07-24 Thread Geert Uytterhoeven

Hi Arnd,

On Fri, Jul 21, 2023 at 10:29 AM Arnd Bergmann  wrote:
> On Fri, Jul 21, 2023, at 06:59, Michael Ellerman wrote:
> > Arnd Bergmann  writes:
> >> From: Arnd Bergmann 
> >>
> >> The list of dependencies here is phrased as an opt-out, but this is missing
> >> a lot of architectures that don't actually support VGA consoles, and some
> >> of the entries are stale:
> >>
> >>  - powerpc used to support VGA consoles in the old arch/ppc codebase, but
> >>the merged arch/powerpc never did
> >
> > Not disputing this, but how did you come to that conclusion? I grepped
> > around and couldn't convince myself whether it can work on powerpc or
> > not. ie. currently it's possible to enable CONFIG_VGA_CONSOLE and
> > powerpc does have a struct screen_info defined which seems like it would
> > allow vgacon_startup() to complete.
>
> The VGA console needs both screen_info and vga_con to work. In arch/ppc
> we had both, but in arch/powerpc we only retained the screen_info:
>
> $ git grep vga_con v2.6.26 -- arch/ppc arch/ppc64 arch/powerpc
> v2.6.26:arch/ppc/platforms/pplus.c: conswitchp = _con;
> v2.6.26:arch/ppc/platforms/prep_setup.c:conswitchp = _con;
>
> so after arch/ppc was removed, this became impossible to use on both
> pplus and prep. These two platforms were also (as far as I can tell)
> the only ones to support vga16fb as an alternative to vgacon, but
> both platforms were removed later on.

I did use vgacon and vga16fb on CHRP on a second video card
(initialized using Gabriel Paubert's x86 BIOS emulator), but that was
definitely before the advent of arch/powerpc/.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 00/18] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags

2023-07-14 Thread Geert Uytterhoeven

Hi Thomas,

On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann  wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
> and have no further effect.
>
> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
> split this by the way the fb_info struct is being allocated. All flags
> are cleared to zero during the allocation.
>
> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
> an actual bug in how arch/sh uses the token for struct fb_videomode,
> which is unrelated.
>
> Patch 17 removes both flag constants from  and patch 18
> documents the zero'ed memory returned by framebuffer_alloc().
>
> v3:
> * sh: include board name in commit message (Adrian)
> * docs: reword text (Miguel)

Thanks for the update!

>   fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
>   fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
>   fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
>   fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers

Four patches with the exact same one-line summary. Please make them
unique.

>   fbdev: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers
>   fbdev: Remove flag FBINFO_FLAG_DEFAULT from fbdev drivers

Two patches with the exact same one-line summary. Please make them
unique.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 00/17] fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT flags

2023-07-11 Thread Geert Uytterhoeven

Hi Helge,

On Tue, Jul 11, 2023 at 5:26 PM Helge Deller  wrote:
> On 7/11/23 16:47, Sam Ravnborg wrote:
> > On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
> >> Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
> >>> On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> >>>> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> >>>> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> >>>> useful when fbdev had special handling for driver modules. With
> >>>> commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
> >>>> and have no further effect.
> >>>>
> >>>> Patches 1 to 7 remove FBINFO_DEFAULT from drivers. Patches 2 to 5
> >>>> split this by the way the fb_info struct is being allocated. All flags
> >>>> are cleared to zero during the allocation.
> >>>>
> >>>> Patches 8 to 16 do the same for FBINFO_FLAG_DEFAULT. Patch 8 fixes
> >>>> an actual bug in how arch/sh uses the tokne for struct fb_videomode,
> >>>> which is unrelated.
> >>>>
> >>>> Patch 17 removes both flag constants from 
> >>>
> >>> We have a few more flags that are unused - should they be nuked too?
> >>> FBINFO_HWACCEL_FILLRECT
> >>> FBINFO_HWACCEL_ROTATE
> >>> FBINFO_HWACCEL_XPAN
> >>
> >> It seems those are there for completeness. Nothing sets _ROTATE,
>
> I think some fbdev drivers had hardware acceleration for ROTATE in the
> past. HWACCEL_XPAN is still in some drivers.
>
> >> the others are simply never checked. According to the comments,
> >> some are required, some are optional. I don't know what that
> >> means.
>
> I think it's OK if you remove those flags which aren't used anywhere,
> e.g. FBINFO_HWACCEL_ROTATE.

Indeed.

> >> IIRC there were complains about performance when Daniel tried to remove
> >> fbcon acceleration, so not all _HWACCEL_ flags are unneeded.
>
> Correct. I think COPYAREA and FILLRECT are the bare minimum to accelerate
> fbcon, IMAGEBLIT is for showing the tux penguin (?),
> XPAN/YPAN and YWRAP for some hardware screen panning needed by some drivers
> (not sure if this is still used as I don't have such hardware, Geert?).

Yes, they are used.  Anything that is handled in drivers/video/fbdev/core/
is used:

$ git grep  HWACCEL_ -- drivers/video/fbdev/core/
drivers/video/fbdev/core/fbcon.c:   if ((info->flags &
FBINFO_HWACCEL_COPYAREA) &&
drivers/video/fbdev/core/fbcon.c:   !(info->flags &
FBINFO_HWACCEL_DISABLED))
drivers/video/fbdev/core/fbcon.c:   int good_pan = (cap &
FBINFO_HWACCEL_YPAN) &&
drivers/video/fbdev/core/fbcon.c:   int good_wrap = (cap &
FBINFO_HWACCEL_YWRAP) &&
drivers/video/fbdev/core/fbcon.c:   int fast_copyarea = (cap &
FBINFO_HWACCEL_COPYAREA) &&
drivers/video/fbdev/core/fbcon.c:   !(cap &
FBINFO_HWACCEL_DISABLED);
drivers/video/fbdev/core/fbcon.c:   int fast_imageblit = (cap &
FBINFO_HWACCEL_IMAGEBLIT) &&
drivers/video/fbdev/core/fbcon.c:   !(cap &
FBINFO_HWACCEL_DISABLED);

BTW, I'm surprised FBINFO_HWACCEL_FILLRECT is not handled.
But looking at the full history, it never was...

> >> Leaving them in for reference/completeness might be an option; or not. I
> >> have no strong feelings about those flags.
>
> I'd say drop FBINFO_HWACCEL_ROTATE at least ?

Agreed.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] rtc: Kconfig: select REGMAP for RTC_DRV_DS1307

2023-07-06 Thread Geert Uytterhoeven

On Thu, Jul 6, 2023 at 9:50 AM Geert Uytterhoeven  wrote:
> On Thu, Jul 6, 2023 at 8:14 AM Benjamin Gray  wrote:
> > On Thu, 2023-07-06 at 05:13 +, Christophe Leroy wrote:
> > > Le 05/07/2023 à 02:30, Benjamin Gray a écrit :
> > > > The drivers/rtc/rtc-ds1307.c driver has a direct dependency on
> > > > struct regmap_config, which is guarded behind CONFIG_REGMAP.
> > > >
> > > > Commit 70a640c0efa7 ("regmap: REGMAP_KUNIT should not select
> > > > REGMAP")
> > > > exposed this by disabling the default pick unless KUNIT_ALL_TESTS
> > > > is
> > > > set, causing the ppc64be allnoconfig build to fail.
> > > >
> > > > Signed-off-by: Benjamin Gray 
> > > > ---
> > > >   drivers/rtc/Kconfig | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > > > index ffca9a8bb878..7455ebd189fe 100644
> > > > --- a/drivers/rtc/Kconfig
> > > > +++ b/drivers/rtc/Kconfig
> > > > @@ -246,6 +246,7 @@ config RTC_DRV_AS3722
> > > >
> > > >   config RTC_DRV_DS1307
> > > > tristate "Dallas/Maxim DS1307/37/38/39/40/41, ST M41T00,
> > > > EPSON RX-8025, ISL12057"
> > > > +   select REGMAP
> > >
> > > As far as I can see, REGMAP defaults to Y when REGMAP_I2C is
> > > selected.
> > > Can you explain more in details why you have to select it explicitely
> > > ?
> > > If there is something wrong with the logic, then the logic should be
> > > fixed instead of just adding a selection of REGMAP for that
> > > particular
> > > RTC_DRV_DS1307. Because others like RTC_DRV_ABB5ZES3 or
> > > RTC_DRV_ABEOZ9
> > > might have the exact same problem.
> >
> > Right, yeah, I don't want to assert this patch is the correct solution,
> > sending it was more to offer a fix and allow discussion if it should be
> > resolved some other way (so thanks for replying, I appreciate it).
> >
> > In terms of why I made this patch, the way I see it, if a config option
> > requires another config option be set, then "selects" is the natural
> > way of phrasing this dependency. "default" on the REGMAP side seems
> > weird. If it's a default, does that mean it can be overridden? But
> > RTC_DRV_DS1307 *requires* REGMAP; it's not just a "would be nice". The
> > build breaks without it.
> >
> > But maybe KConfig works differently to my assumptions. Maybe the
> > referenced patch that causes the build failure is actually incorrect
> > (CC Geert). I spoke with Joel Stanley (CC) and he indicated you're not
> > supposed to depend on REGMAP like KUnit does?
>
> Thanks for CCing me!
>
> Looks like I made a really silly mistake here: my patch not only allows
> the user to enable REGMAP manually (for the test), but also to disable
> it manually, regardless if there are users or not :-(
>
> I think the proper fix is to replace the "default y if ..." by
> "select REGMAP" for all users.

I have sent a patch to do so, followed by a few related fixes
https://lore.kernel.org/r/525c37a568b10623ffb2d108850afd7e37f9350e.1688643442.git.ge...@linux-m68k.org

Thanks!


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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] rtc: Kconfig: select REGMAP for RTC_DRV_DS1307

2023-07-06 Thread Geert Uytterhoeven

Hi Benjamin,

On Thu, Jul 6, 2023 at 8:14 AM Benjamin Gray  wrote:
> On Thu, 2023-07-06 at 05:13 +, Christophe Leroy wrote:
> > Le 05/07/2023 à 02:30, Benjamin Gray a écrit :
> > > The drivers/rtc/rtc-ds1307.c driver has a direct dependency on
> > > struct regmap_config, which is guarded behind CONFIG_REGMAP.
> > >
> > > Commit 70a640c0efa7 ("regmap: REGMAP_KUNIT should not select
> > > REGMAP")
> > > exposed this by disabling the default pick unless KUNIT_ALL_TESTS
> > > is
> > > set, causing the ppc64be allnoconfig build to fail.
> > >
> > > Signed-off-by: Benjamin Gray 
> > > ---
> > >   drivers/rtc/Kconfig | 1 +
> > >   1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > > index ffca9a8bb878..7455ebd189fe 100644
> > > --- a/drivers/rtc/Kconfig
> > > +++ b/drivers/rtc/Kconfig
> > > @@ -246,6 +246,7 @@ config RTC_DRV_AS3722
> > >
> > >   config RTC_DRV_DS1307
> > > tristate "Dallas/Maxim DS1307/37/38/39/40/41, ST M41T00,
> > > EPSON RX-8025, ISL12057"
> > > +   select REGMAP
> >
> > As far as I can see, REGMAP defaults to Y when REGMAP_I2C is
> > selected.
> > Can you explain more in details why you have to select it explicitely
> > ?
> > If there is something wrong with the logic, then the logic should be
> > fixed instead of just adding a selection of REGMAP for that
> > particular
> > RTC_DRV_DS1307. Because others like RTC_DRV_ABB5ZES3 or
> > RTC_DRV_ABEOZ9
> > might have the exact same problem.
>
> Right, yeah, I don't want to assert this patch is the correct solution,
> sending it was more to offer a fix and allow discussion if it should be
> resolved some other way (so thanks for replying, I appreciate it).
>
> In terms of why I made this patch, the way I see it, if a config option
> requires another config option be set, then "selects" is the natural
> way of phrasing this dependency. "default" on the REGMAP side seems
> weird. If it's a default, does that mean it can be overridden? But
> RTC_DRV_DS1307 *requires* REGMAP; it's not just a "would be nice". The
> build breaks without it.
>
> But maybe KConfig works differently to my assumptions. Maybe the
> referenced patch that causes the build failure is actually incorrect
> (CC Geert). I spoke with Joel Stanley (CC) and he indicated you're not
> supposed to depend on REGMAP like KUnit does?

Thanks for CCing me!

Looks like I made a really silly mistake here: my patch not only allows
the user to enable REGMAP manually (for the test), but also to disable
it manually, regardless if there are users or not :-(

I think the proper fix is to replace the "default y if ..." by
"select REGMAP" for all users.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper

2023-07-03 Thread Geert Uytterhoeven

Hi Arnd,

On Mon, Mar 27, 2023 at 2:16 PM Arnd Bergmann  wrote:
> From: Arnd Bergmann 
>
> The arm version of the arch_sync_dma_for_cpu() function annotates pages as
> PG_dcache_clean after a DMA, but no other architecture does this here. On
> ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
> to use the same hook in order to have identical arch_sync_dma_for_cpu()
> semantics as all other architectures.
>
> Splitting this out has multiple effects:
>
>  - for dma-direct, this now gets called after arch_sync_dma_for_cpu()
>for DMA_FROM_DEVICE mappings, but not for DMA_BIDIRECTIONAL. While
>it would not be harmful to keep doing it for bidirectional mappings,
>those are apparently not used in any callers that care about the flag.
>
>  - Since arm has its own dma-iommu abstraction, this now also needs to
>call the same function, so the calls are added there to mirror the
>dma-direct version.
>
>  - Like dma-direct, the dma-iommu version now marks the dcache clean
>for both coherent and noncoherent devices after a DMA, but it only
>does this for DMA_FROM_DEVICE, not DMA_BIDIRECTIONAL.
>
> [ HELP NEEDED: can anyone confirm that it is a correct assumption
>   on arm that a cache-coherent device writing to a page always results
>   in it being in a PG_dcache_clean state like on ia64, or can a device
>   write directly into the dcache?]
>
> Signed-off-by: Arnd Bergmann 

Thanks for your patch, which is now commit 322dbe898f82fd8a
("ARM: dma-mapping: split out arch_dma_mark_clean() helper") in
esmil/jh7100-dmapool.

If CONFIG_ARM_DMA_USE_IOMMU=y, the build fails.

> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c

> @@ -1294,6 +1298,17 @@ static int arm_iommu_map_sg(struct device *dev, struct 
> scatterlist *sg,
> return -EINVAL;
>  }
>
> +static void arm_iommu_sync_dma_for_cpu(phys_addr_t phys, size_t len,
> +  enum dma_data_direction dir,
> +  bool dma_coherent)
> +{
> +   if (!dma_coherent)
> +   arch_sync_dma_for_cpu(phys, s->length, dir);

s/s->length/len/

> +
> +   if (dir == DMA_FROM_DEVICE)
> +   arch_dma_mark_clean(phys, s->length);

Likewise.

> +}
> +
>  /**
>   * arm_iommu_unmap_sg - unmap a set of SG buffers mapped by dma_map_sg
>   * @dev: valid struct device pointer

> @@ -1425,9 +1438,9 @@ static void arm_iommu_unmap_page(struct device *dev, 
> dma_addr_t handle,
> if (!iova)
> return;
>
> -   if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) {
> +   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))

Missing opening curly brace.

> phys = iommu_iova_to_phys(mapping->domain, handle);
> -   arch_sync_dma_for_cpu(phys, size, dir);
> +   arm_iommu_sync_dma_for_cpu(phys, size, dir, 
> dev->dma_coherent);
> }
>
> iommu_unmap(mapping->domain, iova, len);

With the above fixed, it builds and boots fine (on R-Car M2-W).

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation

2023-06-27 Thread Geert Uytterhoeven

On Thu, Apr 13, 2023 at 2:52 PM Arnd Bergmann  wrote:
> On Thu, Apr 13, 2023, at 14:13, Biju Das wrote:
> > FYI, this patch breaks on RZ/G2L SMARC EVK board and Arnd will send V2
> > for fixing this issue.
> >
> > [10:53]  [3.384408] Unable to handle kernel paging request at
> > virtual address 4afb0080
>
> Right, sorry about this, I accidentally removed the 'phys_to_virt()'
> conversion on arm64.

Meh, I missed that, so I ended up bisecting this same failure...

This patch is now commit 801f1883c4bb70cc ("dma-mapping: replace
custom code with generic implementation") in esmil/jh7100-dmapool,
and broke booting on R-Car Gen3.

The following gmail-whitespace-damaged patch fixes that:

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 97b7cea5eb23aedd..77e0b68b43e5849a 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -15,17 +15,23 @@

 static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
 {
-   dcache_clean_poc(paddr, paddr + size);
+   unsigned long start = (unsigned long)phys_to_virt(paddr);
+
+   dcache_clean_poc(start, start + size);
 }

 static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
 {
-   dcache_inval_poc(paddr, paddr + size);
+   unsigned long start = (unsigned long)phys_to_virt(paddr);
+
+   dcache_inval_poc(start, start + size);
 }

 static inline void arch_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
 {
-   dcache_clean_inval_poc(paddr, paddr + size);
+   unsigned long start = (unsigned long)phys_to_virt(paddr);
+
+   dcache_clean_inval_poc(start, start + size);
 }

 static inline bool arch_sync_dma_clean_before_fromdevice(void)

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v5 24/33] m68k: Convert various functions to use ptdescs

2023-06-25 Thread Geert Uytterhoeven

Hi Vishal,

On Thu, Jun 22, 2023 at 10:58 PM Vishal Moola (Oracle)
 wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
> these to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle) 

Thanks for your patch!

> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h

>  static inline pgd_t *pgd_alloc(struct mm_struct *mm)
>  {
> pgd_t *new_pgd;
> +   struct ptdesc *ptdesc = pagetable_alloc((GFP_DMA | GFP_NOWARN) &

0-day already told you for v3 that GFP_NOWARN does not exist.
Please try cross-compiling your changes:
https://mirrors.edge.kernel.org/pub/tools/crosstool/

> +   ~__GFP_HIGHMEM, 0);
>
> -   new_pgd = (pgd_t *)__get_free_page(GFP_DMA | __GFP_NOWARN);
> -   if (!new_pgd)
> +   if (!ptdesc)
> return NULL;
> +   new_pgd = ptdesc_address(ptdesc);
> +
> 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...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 27/34] nios2: Convert __pte_free_tlb() to use ptdescs

2023-06-14 Thread Geert Uytterhoeven

Hi Dinh,

On Wed, Jun 14, 2023 at 12:17 AM Dinh Nguyen  wrote:
> On 6/12/23 16:04, Vishal Moola (Oracle) wrote:
> > Part of the conversions to replace pgtable constructor/destructors with
> > ptdesc equivalents.
> >
> > Signed-off-by: Vishal Moola (Oracle) 
> > ---
> >   arch/nios2/include/asm/pgalloc.h | 8 
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/nios2/include/asm/pgalloc.h 
> > b/arch/nios2/include/asm/pgalloc.h
> > index ecd1657bb2ce..ce6bb8e74271 100644
> > --- a/arch/nios2/include/asm/pgalloc.h
> > +++ b/arch/nios2/include/asm/pgalloc.h
> > @@ -28,10 +28,10 @@ static inline void pmd_populate(struct mm_struct *mm, 
> > pmd_t *pmd,
> >
> >   extern pgd_t *pgd_alloc(struct mm_struct *mm);
> >
> > -#define __pte_free_tlb(tlb, pte, addr)   \
> > - do {\
> > - pgtable_pte_page_dtor(pte); \
> > - tlb_remove_page((tlb), (pte));  \
> > +#define __pte_free_tlb(tlb, pte, addr) 
> >   \
> > + do {\
> > + pagetable_pte_dtor(page_ptdesc(pte));   \
> > + tlb_remove_page_ptdesc((tlb), (page_ptdesc(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

-- 
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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v9 01/42] mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()

2023-06-13 Thread Geert Uytterhoeven

On Tue, Jun 13, 2023 at 2:13 AM Rick Edgecombe
 wrote:
> The x86 Shadow stack feature includes a new type of memory called shadow
> stack. This shadow stack memory has some unusual properties, which requires
> some core mm changes to function properly.
>
> One of these unusual properties is that shadow stack memory is writable,
> but only in limited ways. These limits are applied via a specific PTE
> bit combination. Nevertheless, the memory is writable, and core mm code
> will need to apply the writable permissions in the typical paths that
> call pte_mkwrite(). Future patches will make pte_mkwrite() take a VMA, so
> that the x86 implementation of it can know whether to create regular
> writable memory or shadow stack memory.
>
> But there are a couple of challenges to this. Modifying the signatures of
> each arch pte_mkwrite() implementation would be error prone because some
> are generated with macros and would need to be re-implemented. Also, some
> pte_mkwrite() callers operate on kernel memory without a VMA.
>
> So this can be done in a three step process. First pte_mkwrite() can be
> renamed to pte_mkwrite_novma() in each arch, with a generic pte_mkwrite()
> added that just calls pte_mkwrite_novma(). Next callers without a VMA can
> be moved to pte_mkwrite_novma(). And lastly, pte_mkwrite() and all callers
> can be changed to take/pass a VMA.
>
> Start the process by renaming pte_mkwrite() to pte_mkwrite_novma() and
> adding the pte_mkwrite() wrapper in linux/pgtable.h. Apply the same
> pattern for pmd_mkwrite(). Since not all archs have a pmd_mkwrite_novma(),
> create a new arch config HAS_HUGE_PAGE that can be used to tell if
> pmd_mkwrite() should be defined. Otherwise in the !HAS_HUGE_PAGE cases the
> compiler would not be able to find pmd_mkwrite_novma().
>
> No functional change.
>
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-al...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c...@vger.kernel.org
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: loonga...@lists.linux.dev
> Cc: linux-m...@lists.linux-m68k.org
> Cc: Michal Simek 
> Cc: Dinh Nguyen 
> Cc: linux-m...@vger.kernel.org
> Cc: openr...@lists.librecores.org
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: sparcli...@vger.kernel.org
> Cc: linux...@lists.infradead.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> Suggested-by: Linus Torvalds 
> Signed-off-by: Rick Edgecombe 
> Link: 
> https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/

>  arch/m68k/include/asm/mcf_pgtable.h  |  2 +-
>  arch/m68k/include/asm/motorola_pgtable.h |  2 +-
>  arch/m68k/include/asm/sun3_pgtable.h |  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 technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 25/34] m68k: Convert various functions to use ptdescs

2023-06-13 Thread Geert Uytterhoeven

On Mon, Jun 12, 2023 at 11:05 PM Vishal Moola (Oracle)
 wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
> 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 Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v1 07/21] m68k/kexec: refactor for kernel/Kconfig.kexec

2023-06-12 Thread Geert Uytterhoeven

On Mon, Jun 12, 2023 at 7:29 PM Eric DeVolder  wrote:
> The kexec and crash kernel options are provided in the common
> kernel/Kconfig.kexec. Utilize the common options and provide
> the ARCH_HAS_ and ARCH_SUPPORTS_ entries to recreate the
> equivalent set of KEXEC and CRASH options.
>
> Signed-off-by: Eric DeVolder 

Reviewed-by: Geert Uytterhoeven 
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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 30/34] sh: Convert pte_free_tlb() to use ptdescs

2023-06-01 Thread Geert Uytterhoeven

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 constructor/destructors with
> > > ptdesc equivalents. Also cleans up some spacing issues.
> > >
> > > Signed-off-by: Vishal Moola (Oracle) 
> >
> > LGTM, so
> > Reviewed-by: Geert Uytterhoeven 
>
> I assume this series is supposed to go through some mm tree?

I think so, so your Acked-by would be appreciated...

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 25/34] m68k: Convert various functions to use ptdescs

2023-06-01 Thread Geert Uytterhoeven

Hi Vishal,

On Wed, May 31, 2023 at 11:32 PM Vishal Moola (Oracle)
 wrote:
> As part of the conversions to replace pgtable constructor/destructors with
> ptdesc equivalents, convert various page table functions to use ptdescs.
>
> Some of the functions use the *get*page*() helper functions. Convert
> these to use pagetable_alloc() and ptdesc_address() instead to help
> standardize page tables further.
>
> Signed-off-by: Vishal Moola (Oracle) 

Thanks for your patch!

> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h
> @@ -7,20 +7,19 @@
>
>  extern inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
>  {
> -   free_page((unsigned long) pte);
> +   pagetable_free(virt_to_ptdesc(pte));
>  }
>
>  extern const char bad_pmd_string[];
>
>  extern inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
>  {
> -   unsigned long page = __get_free_page(GFP_DMA);
> +   struct ptdesc *ptdesc = pagetable_alloc(GFP_DMA | __GFP_ZERO, 0);
>
> -   if (!page)
> +   if (!ptdesc)
> return NULL;
>
> -   memset((void *)page, 0, PAGE_SIZE);
> -   return (pte_t *) (page);
> +   return (pte_t *) (ptdesc_address(ptdesc));

No need to cast "void *" when returning a different pointer type.

>  }
>
>  extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned long address)
> @@ -35,36 +34,36 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, 
> unsigned long address)
>  static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t pgtable,
>   unsigned long address)
>  {
> -   struct page *page = virt_to_page(pgtable);
> +   struct ptdesc *ptdesc = virt_to_ptdesc(pgtable);
>
> -   pgtable_pte_page_dtor(page);
> -   __free_page(page);
> +   pagetable_pte_dtor(ptdesc);
> +   pagetable_free(ptdesc);
>  }
>
>  static inline pgtable_t pte_alloc_one(struct mm_struct *mm)
>  {
> -   struct page *page = alloc_pages(GFP_DMA, 0);
> +   struct ptdesc *ptdesc = pagetable_alloc(GFP_DMA, 0);
> pte_t *pte;
>
> -   if (!page)
> +   if (!ptdesc)
> return NULL;
> -   if (!pgtable_pte_page_ctor(page)) {
> -   __free_page(page);
> +   if (!pagetable_pte_ctor(ptdesc)) {
> +   pagetable_free(ptdesc);
> return NULL;
> }
>
> -   pte = page_address(page);
> -   clear_page(pte);
> +   pte = ptdesc_address(ptdesc);
> +   pagetable_clear(pte);
>
> return pte;
>  }
>
>  static inline void pte_free(struct mm_struct *mm, pgtable_t pgtable)
>  {
> -   struct page *page = virt_to_page(pgtable);
> +   struct ptdesc *ptdesc = virt_to_ptdesc(ptdesc);

virt_to_ptdesc(pgtable)

(You can build this using m5475evb_defconfig)

>
> -   pgtable_pte_page_dtor(page);
> -   __free_page(page);
> +   pagetable_pte_dtor(ptdesc);
> +   pagetable_free(ptdesc);
>  }
>
>  /*
> @@ -75,16 +74,18 @@ static inline void pte_free(struct mm_struct *mm, 
> pgtable_t pgtable)
>
>  static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
>  {
> -   free_page((unsigned long) pgd);
> +   pagetable_free(virt_to_ptdesc(pgd));
>  }
>
>  static inline pgd_t *pgd_alloc(struct mm_struct *mm)
>  {
> pgd_t *new_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_address(ptdesc);

No need to cast "void *" when assigning to a different pointer type.

> +
> memcpy(new_pgd, swapper_pg_dir, PTRS_PER_PGD * sizeof(pgd_t));
> memset(new_pgd, 0, PAGE_OFFSET >> PGDIR_SHIFT);
> return new_pgd;

The rest LGTM.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3 30/34] sh: Convert pte_free_tlb() to use ptdescs

2023-06-01 Thread Geert Uytterhoeven

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{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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] MAINTAINERS: Exclude m68k-only drivers from powerpc entry

2023-05-31 Thread Geert Uytterhoeven

Hi Michael,

CC Finn

On Wed, May 31, 2023 at 2:50 PM Michael Ellerman  wrote:
> The powerpc section has a "F:" entry for drivers/macintosh, matching all
> files in or below drivers/macintosh. That is correct for the most part,
> but there are a couple of m68k-only drivers in the directory, so exclude
> those.
>
> Signed-off-by: Michael Ellerman 

Thanks for your patch!

> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11916,6 +11916,8 @@ L:  linuxppc-dev@lists.ozlabs.org
>  S: Odd Fixes
>  F: arch/powerpc/platforms/powermac/
>  F: drivers/macintosh/
> +X: drivers/macintosh/adb-iop.c
> +X: drivers/macintosh/via-macii.c
>
>  LINUX FOR POWERPC (32-BIT AND 64-BIT)
>  M: Michael Ellerman 

LGTM, as there are already entries for these two files under
"M68K ON APPLE MACINTOSH".
Acked-by: Geert Uytterhoeven 

Which leads us to a related topic: Is Joshua still around?  Should Finn
be added or replace Joshua in the "M68K ON APPLE MACINTOSH" entry?

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] mm/slab: rename CONFIG_SLAB to CONFIG_SLAB_DEPRECATED

2023-05-23 Thread Geert Uytterhoeven

Hi Vlastimil,

Thanks for your patch!

On Tue, May 23, 2023 at 11:12 AM Vlastimil Babka  wrote:
> As discussed at LSF/MM [1] [2] and with no objections raised there,
> deprecate the SLAB allocator. Rename the user-visible option so that
> users with CONFIG_SLAB=y get a new prompt with explanation during make
> oldconfig, while make olddefconfig will just switch to SLUB.
>
> In all defconfigs with CONFIG_SLAB=y remove the line so those also
> switch to SLUB. Regressions due to the switch should be reported to
> linux-mm and slab maintainers.

Technically, removing these lines from the defconfig files does not
have any impact, right?
And it removes one more sync point indicating the last time some
defconfig files were (not) updated by their maintainers ;-)

> [1] https://lore.kernel.org/all/4b9fc9c6-b48c-198f-5f80-811a44737...@suse.cz/
> [2] https://lwn.net/Articles/932201/
>
> Signed-off-by: Vlastimil Babka 

>  arch/m68k/configs/amiga_defconfig   |  1 -
>  arch/m68k/configs/apollo_defconfig  |  1 -
>  arch/m68k/configs/atari_defconfig   |  1 -
>  arch/m68k/configs/bvme6000_defconfig|  1 -
>  arch/m68k/configs/hp300_defconfig   |  1 -
>  arch/m68k/configs/mac_defconfig |  1 -
>  arch/m68k/configs/multi_defconfig   |  1 -
>  arch/m68k/configs/mvme147_defconfig |  1 -
>  arch/m68k/configs/mvme16x_defconfig |  1 -
>  arch/m68k/configs/q40_defconfig |  1 -
>  arch/m68k/configs/sun3_defconfig|  1 -
>  arch/m68k/configs/sun3x_defconfig   |  1 -

Regardless,
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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v5 RESEND 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros

2023-05-16 Thread Geert Uytterhoeven

On Mon, May 15, 2023 at 11:14 AM Baoquan He  wrote:
> Let's use '#define ioremap_xx' and "#ifdef ioremap_xx" instead.
>
> For each architecture to remove defined ARCH_HAS_IOREMAP_xx macros in
> To remove defined ARCH_HAS_IOREMAP_xx macros in  of each ARCH,
> the ARCH's own ioremap_wc|wt|np definition need be above
> "#include . Otherwise the redefinition error would
> be seen during compiling. So the relevant adjustments are made to avoid
> compiling error:
>
>   loongarch:
>   - doesn't include , defining ARCH_HAS_IOREMAP_WC
> is redundant, so simply remove it.
>
>   m68k:
>   - selected GENERIC_IOMAP,  has been added in
> , and  is included above
> , so simply remove ARCH_HAS_IOREMAP_WT defining.
>
>   mips:
>   - move "#include " below ioremap_wc definition
> in 
>
>   powerpc:
>   - remove "#include " in  because it's
> duplicated with the one in , let's rely on the
> latter.
>
>   x86:
>   - selected GENERIC_IOMAP, remove #include  in
> the middle of . Let's rely on .
>
> Signed-off-by: Baoquan He 

>  arch/m68k/include/asm/io_mm.h   | 2 --
>  arch/m68k/include/asm/kmap.h| 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 technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC PATCH v2] fs/xattr: add *at family syscalls

2023-05-11 Thread Geert Uytterhoeven

Hi Christian,

On Thu, May 11, 2023 at 5:10 PM Christian Göttsche
 wrote:
> Add the four syscalls setxattrat(), getxattrat(), listxattrat() and
> removexattrat().  Those can be used to operate on extended attributes,
> especially security related ones, either relative to a pinned directory
> or on a file descriptor without read access, avoiding a
> /proc//fd/ detour, requiring a mounted procfs.
>
> One use case will be setfiles(8) setting SELinux file contexts
> ("security.selinux") without race conditions.
>
> Add XATTR flags to the private namespace of AT_* flags.
>
> Use the do_{name}at() pattern from fs/open.c.
>
> Use a single flag parameter for extended attribute flags (currently
> XATTR_CREATE and XATTR_REPLACE) and *at() flags to not exceed six
> syscall arguments in setxattrat().
>
> Previous approach ("f*xattr: allow O_PATH descriptors"): 
> https://lore.kernel.org/all/20220607153139.35588-1-cgzo...@googlemail.com/
> v1 discussion: 
> https://lore.kernel.org/all/20220830152858.14866-2-cgzo...@googlemail.com/
>
> Signed-off-by: Christian Göttsche 

Thanks for your patch!

The syscall numbers conflict with those used in "[PATCH] cachestat:
wire up cachestat for other architectures", so this needs some
synchronization.
https://lore.kernel.org/linux-sh/20230510195806.2902878-1-npha...@gmail.com

>  arch/m68k/kernel/syscalls/syscall.tbl   |   4 +

For m68k:
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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] cachestat: wire up cachestat for other architectures

2023-05-11 Thread Geert Uytterhoeven

Hi Nat,

On Wed, May 10, 2023 at 9:58 PM Nhat Pham  wrote:
> cachestat is previously only wired in for x86 (and architectures using
> the generic unistd.h table):
>
> https://lore.kernel.org/lkml/20230503013608.2431726-1-npha...@gmail.com/
>
> This patch wires cachestat in for all the other architectures.
>
> Signed-off-by: Nhat Pham 
> ---
>  arch/alpha/kernel/syscalls/syscall.tbl  | 1 +
>  arch/arm/tools/syscall.tbl  | 1 +

Looking at the last addition of a syscall (commit 21b084fdf2a49ca1
("mm/mempolicy: wire up syscall set_mempolicy_home_node"), it looks
like you forgot to update arm64 in compat mode? Or is that not needed?

>  arch/ia64/kernel/syscalls/syscall.tbl   | 1 +
>  arch/m68k/kernel/syscalls/syscall.tbl   | 1 +

For m68k:
Acked-by: Geert Uytterhoeven 

>  arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
>  arch/mips/kernel/syscalls/syscall_n32.tbl   | 1 +
>  arch/mips/kernel/syscalls/syscall_n64.tbl   | 1 +
>  arch/mips/kernel/syscalls/syscall_o32.tbl   | 1 +
>  arch/parisc/kernel/syscalls/syscall.tbl | 1 +
>  arch/powerpc/kernel/syscalls/syscall.tbl| 1 +
>  arch/s390/kernel/syscalls/syscall.tbl   | 1 +
>  arch/sh/kernel/syscalls/syscall.tbl | 1 +
>  arch/sparc/kernel/syscalls/syscall.tbl  | 1 +
>  arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
>  14 files changed, 14 insertions(+)

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 05/23] m68k: allow pte_offset_map[_lock]() to fail

2023-05-11 Thread Geert Uytterhoeven

Hi Hugh,

On Thu, May 11, 2023 at 4:58 AM Hugh Dickins  wrote:
> On Wed, 10 May 2023, Geert Uytterhoeven wrote:
> > On Wed, May 10, 2023 at 6:48 AM Hugh Dickins  wrote:
> > > In rare transient cases, not yet made possible, pte_offset_map() and
> > > pte_offset_map_lock() may not find a page table: handle appropriately.
> > >
> > > Restructure cf_tlb_miss() with a pte_unmap() (previously omitted)
> > > at label out, followed by one local_irq_restore() for all.
> >
> > That's a bug fix, which should be a separate patch?
>
> No, that's not a bug fix for the current tree, since m68k does not
> offer CONFIG_HIGHPTE, so pte_unmap() is never anything but a no-op
> for m68k (see include/linux/pgtable.h).
>
> But I want to change pte_unmap() to do something even without
> CONFIG_HIGHPTE, so have to fix up any such previously harmless
> omissions in this series first.

OK.

> > > --- a/arch/m68k/include/asm/mmu_context.h
> > > +++ b/arch/m68k/include/asm/mmu_context.h
> > > @@ -99,7 +99,7 @@ static inline void load_ksp_mmu(struct task_struct 
> > > *task)
> > > p4d_t *p4d;
> > > pud_t *pud;
> > > pmd_t *pmd;
> > > -   pte_t *pte;
> > > +   pte_t *pte = NULL;
> > > unsigned long mmuar;
> > >
> > > local_irq_save(flags);
> > > @@ -139,7 +139,7 @@ static inline void load_ksp_mmu(struct task_struct 
> > > *task)
> > >
> > > pte = (mmuar >= PAGE_OFFSET) ? pte_offset_kernel(pmd, mmuar)
> > >  : pte_offset_map(pmd, mmuar);
> > > -   if (pte_none(*pte) || !pte_present(*pte))
> > > +   if (!pte || pte_none(*pte) || !pte_present(*pte))
> > > goto bug;
> >
> > If the absence of a pte is to become a non-abnormal case, it should
> > probably jump to "end" instead, to avoid spamming the kernel log.
>
> I don't think so (but of course it's hard for you to tell, without
> seeing all completed series of series).  If pmd_none(*pmd) can safely
> goto bug just above, and pte_none(*pte) goto bug here, well, the !pte
> case is going to be stranger than either of those.
>
> My understanding of this function, load_ksp_mmu(), is that it's dealing
> at context switch with a part of userspace which very much needs to be
> present: whatever keeps that from being swapped out or migrated at
> present, will be sure to keep the !pte case away - we cannot steal its
> page table just at random (and a THP on m68k would be surprising too).
>
> Though there is one case I can think of which will cause !pte here,
> and so goto bug: if the pmd entry has got corrupted, and counts as
> pmd_bad(), which will be tested (and cleared) in pte_offset_map().
> But it is okay to report a bug in that case.
>
> I can certainly change this to goto end instead if you still prefer,
> no problem; but I'd rather keep it as is, if only for me to be proved
> wrong by you actually seeing spam there.

OK, makes sense.

> > > @@ -161,6 +161,8 @@ static inline void load_ksp_mmu(struct task_struct 
> > > *task)
> > >  bug:
> > > pr_info("ksp load failed: mm=0x%p ksp=0x08%lx\n", mm, mmuar);
> > >  end:
> > > +   if (pte && mmuar < PAGE_OFFSET)
> > > +   pte_unmap(pte);
> >
> > Is this also a bugfix, not mentioned in the patch description?
>
> I'm not sure whether you're referring to the pte_unmap() which we
> already discussed above, or you're seeing something else in addition;
> but I don't think there's a bugfix here, just a rearrangement because
> we now want lots of cases to do the pte_unmap() and local_irq_restore().

I was referring to the addition of pte_unmap().
As per your explanation above, this is not a bugfix.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 05/23] m68k: allow pte_offset_map[_lock]() to fail

2023-05-10 Thread Geert Uytterhoeven

Hi Hugh,

Thanks for your patch!

On Wed, May 10, 2023 at 6:48 AM Hugh Dickins  wrote:
> In rare transient cases, not yet made possible, pte_offset_map() and
> pte_offset_map_lock() may not find a page table: handle appropriately.
>
> Restructure cf_tlb_miss() with a pte_unmap() (previously omitted)
> at label out, followed by one local_irq_restore() for all.

That's a bug fix, which should be a separate patch?

>
> Signed-off-by: Hugh Dickins 


> --- a/arch/m68k/include/asm/mmu_context.h
> +++ b/arch/m68k/include/asm/mmu_context.h
> @@ -99,7 +99,7 @@ static inline void load_ksp_mmu(struct task_struct *task)
> p4d_t *p4d;
> pud_t *pud;
> pmd_t *pmd;
> -   pte_t *pte;
> +   pte_t *pte = NULL;
> unsigned long mmuar;
>
> local_irq_save(flags);
> @@ -139,7 +139,7 @@ static inline void load_ksp_mmu(struct task_struct *task)
>
> pte = (mmuar >= PAGE_OFFSET) ? pte_offset_kernel(pmd, mmuar)
>  : pte_offset_map(pmd, mmuar);
> -   if (pte_none(*pte) || !pte_present(*pte))
> +   if (!pte || pte_none(*pte) || !pte_present(*pte))
> goto bug;

If the absence of a pte is to become a non-abnormal case, it should
probably jump to "end" instead, to avoid spamming the kernel log.

>
> set_pte(pte, pte_mkyoung(*pte));
> @@ -161,6 +161,8 @@ static inline void load_ksp_mmu(struct task_struct *task)
>  bug:
> pr_info("ksp load failed: mm=0x%p ksp=0x08%lx\n", mm, mmuar);
>  end:
> +   if (pte && mmuar < PAGE_OFFSET)
> +   pte_unmap(pte);

Is this also a bugfix, not mentioned in the patch description?

> local_irq_restore(flags);
>  }
>

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary

Hi David,

On Wed, Apr 5, 2023 at 11:37 PM David Laight  wrote:
> From: Linuxppc-dev Arnd Bergmann
> > Sent: 05 April 2023 21:32
> >
> > On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote:
> > > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle  
> > > wrote:
> > >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
> > >>> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
> > >>> Port access. In a future patch HAS_IOPORT=n will disable compilation of
> > >>> the I/O accessor functions inb()/outb() and friends on architectures
> > >>> which can not meaningfully support legacy I/O spaces such as s390.
> > >>> >>
> > >>Gentle ping. As far as I can tell this hasn't been picked to any tree
> > >>sp far but also hasn't seen complains so I'm wondering if I should send
> > >>a new version of the combined series of this patch plus the added
> > >>HAS_IOPORT dependencies per subsystem or wait until this is picked up.
> > >
> > > You need this on a system supporting not just ISA but also PCI.
> > >
> > > Typically on non-x86 architectures this is simply mapped into a memory 
> > > window.
> >
> > I'm pretty confident that the list is correct here, as the HAS_IOPORT
> > symbol is enabled exactly for the architectures that have a way to
> > map the I/O space. PCIe generally works fine without I/O space, the
> > only exception are drivers for devices that were around as early PCI.
>
> Isn't there a difference between cpu that have inb()/outb() (probably
> only x86?) and architectures (well computer designs) that can generate
> PCI 'I/O' cycles by some means.
> It isn't even just PCI I/O cycles, I've used an ARM cpu (SA1100)
> that mapped a chuck of physical address space onto PCMCIA I/O cycles.
>
> If the hardware can map a PCI 'IO' bar into normal kernel address
> space then the bar and accesses can be treated exactly like a memory bar.
> This probably leaves x86 as the outlier where you need (IIRC) io_readl()
> and friends that can generate in/out instructions for those accesses.
>
> There are also all the x86 ISA devices which need in/out instructions.
> But (with the likely exception of the UART) they are pretty much
> platform specific.
>
> So, to my mind at least, HAS_IOPORT is just the wrong question.

Not all PCI controllers support mapping the I/O bar in MMIO space, so
in general you cannot say that CONFIG_PCI=y means CONFIG_HAS_IOPORT=y.

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 journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 08/19] arch/m68k: Implement with generic helpers

On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann  wrote:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> v2:
> * provide empty fb_pgprotect() on non-MMU systems
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Geert Uytterhoeven 

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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 07/19] arch/m68k: Merge variants of fb_pgprotect() into single function

On Thu, Apr 6, 2023 at 4:30 PM Thomas Zimmermann  wrote:
> Merge all variants of fb_pgprotect() into a single function body.
> There are two different cases for MMU systems. For non-MMU systems,
> the function body will be empty. No functional changes, but this
> will help with the switch to .
>
> Signed-off-by: Thomas Zimmermann 

Reviewed-by: Geert Uytterhoeven 
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 people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers