Re: [PATCH 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM
Hi Mike,
On 29/10/20 12:16 AM, Mike Rapoport wrote:
Hi Geert,
On Wed, Oct 28, 2020 at 10:25:49AM +0100, Geert Uytterhoeven wrote:
Hi Mike,
On Tue, Oct 27, 2020 at 12:31 PM Mike Rapoport wrote:
From: Mike Rapoport
The pg_data_t node structures and their initialization currently depends on
!CONFIG_SINGLE_MEMORY_CHUNK. Since they are required only for DISCONTIGMEM
make this dependency explicit and replace usage of
CONFIG_SINGLE_MEMORY_CHUNK with CONFIG_DISCONTIGMEM where appropriate.
The CONFIG_SINGLE_MEMORY_CHUNK was implicitly disabled on the ColdFire MMU
variant, although it always presumed a single memory bank. As there is no
actual need for DISCONTIGMEM in this case, make sure that ColdFire MMU
systems set CONFIG_SINGLE_MEMORY_CHUNK to 'y'.
Signed-off-by: Mike Rapoport
Thanks for your patch!
---
arch/m68k/Kconfig.cpu | 6 +++---
arch/m68k/include/asm/page_mm.h | 2 +-
arch/m68k/mm/init.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
Is there any specific reason you didn't convert the checks for
CONFIG_SINGLE_MEMORY_CHUNK in arch/m68k/kernel/setup_mm.c
In arch/m68k/kernel/setup_mm.c the CONFIG_SINGLE_MEMORY_CHUNK is needed
for the case when a system has two banks, the kernel is loaded into the
second bank and so the first bank cannot be used as normal memory. It
does not matter what memory model will be used in this case.
That case used to be detected just fine at run time (by dint of the
second memory chunk having an address below the first; the chunk the
kernel resides in is always listed first), even without using
CONFIG_SINGLE_MEMORY_CHUNK.
Unless you changed that behaviour (and I see nothing in your patch that
would indicate that), this is still true.
Converting the check as Geert suggested, without also adding a test for
out-of-order memory bank addresses, would implicitly treat DISCONTIGMEM
as SINGLE_MEMORY_CHUNK, regardless of bank ordering. I don't think that
is what we really want?
Cheers,
Michael
and arch/m68k/include/asm/virtconvert.h?
I remember I had build errors and troubles with include file
dependencies if I changed it there, but I might be mistaken. I'll
recheck again.
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
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Hi Geert, Niklas,
Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven:
Hi Niklas,
On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle wrote:
We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms
inb()/outb() etc are currently just stubs in asm-generic/io.h which when
called will cause a NULL pointer access which some compilers actually
detect and warn about.
The dependencies on HAS_IOPORT in drivers as well as ifdefs for
HAS_IOPORT specific sections will be added in subsequent patches on
a per subsystem basis. Then a final patch will ifdef the I/O access
functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
into a compile-time warning.
Link:
https://lore.kernel.org/lkml/CAHk-=wg80je=k7madf4e7wrrnp37e3qh6y10svhdc7o8sz_...@mail.gmail.com/
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
Thanks for your patch!
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -16,6 +16,7 @@ config M68K
select GENERIC_CPU_DEVICES
select GENERIC_IOMAP
select GENERIC_IRQ_SHOW
+ select HAS_IOPORT
select HAVE_AOUT if MMU
select HAVE_ASM_MODVERSIONS
select HAVE_DEBUG_BUGVERBOSE
This looks way too broad to me: most m68k platform do not have I/O
port access support.
My gut feeling says:
select HAS_IOPORT if PCI || ISA
but that might miss some intricate details...
In particular, this misses the Atari ROM port ISA adapter case -
select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA
might do instead.
Cheers,
Michael
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
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Hi Arnd, Am 29.12.2021 um 16:41 schrieb Arnd Bergmann: On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz wrote: Am 28.12.2021 um 23:08 schrieb Geert Uytterhoeven: On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle wrote: We introduce a new HAS_IOPORT Kconfig option to gate 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. On these platforms inb()/outb() etc are currently just stubs in asm-generic/io.h which when called will cause a NULL pointer access which some compilers actually detect and warn about. The dependencies on HAS_IOPORT in drivers as well as ifdefs for HAS_IOPORT specific sections will be added in subsequent patches on a per subsystem basis. Then a final patch will ifdef the I/O access functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT into a compile-time warning. Link: https://lore.kernel.org/lkml/CAHk-=wg80je=k7madf4e7wrrnp37e3qh6y10svhdc7o8sz_...@mail.gmail.com/ Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle Thanks for your patch! --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -16,6 +16,7 @@ config M68K select GENERIC_CPU_DEVICES select GENERIC_IOMAP select GENERIC_IRQ_SHOW + select HAS_IOPORT select HAVE_AOUT if MMU select HAVE_ASM_MODVERSIONS select HAVE_DEBUG_BUGVERBOSE This looks way too broad to me: most m68k platform do not have I/O port access support. My gut feeling says: select HAS_IOPORT if PCI || ISA but that might miss some intricate details... In particular, this misses the Atari ROM port ISA adapter case - select HAS_IOPORT if PCI || ISA || ATARI_ROM_ISA might do instead. Right, makes sense. I had suggested to go the easy way and assume that each architecture would select HAS_IOPORT if any configuration supports it, but it looks like for m68k there is a clearly defined set of platforms that do. Note that for the platforms that don't set any of the three symbols, the fallback makes inb() an alias for readb() with a different argument type, so there may be m68k specific drivers that rely on this, but those would already be broken if ATARI_ROM_ISA is set. I'd hope not - we spent some effort to make sure setting ATARI_ROM_ISA does not affect other m68k platforms when e.g. building multiplatform kernels. Replacing inb() by readb() without any address translation won't do much good for m68k though - addresses in the traditional ISA I/O port range would hit the (unmapped) zero page. Cheers, Michael Arnd ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Hi Arnd, Am 30.12.2021 um 14:48 schrieb Arnd Bergmann: On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz wrote: Am 29.12.2021 um 16:41 schrieb Arnd Bergmann: On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz wrote: I'd hope not - we spent some effort to make sure setting ATARI_ROM_ISA does not affect other m68k platforms when e.g. building multiplatform kernels. Ok Replacing inb() by readb() without any address translation won't do much good for m68k though - addresses in the traditional ISA I/O port range would hit the (unmapped) zero page. Correct, this is exactly the problem that Niklas is trying to solve here: we do have drivers that hit this bug, and on s390 clang actually produces a compile-time error for drivers that cause a NULL pointer dereference this way. Thanks for clarifying - I only saw Geert's CC and failed to go back to the start of the thread. What some other architectures do is to rely on inb()/outb() to have a zero-based offset, and use an io_offset in PCI buses to ensure that a low port number on the bus gets translated into a pointer value for the virtual mapping in the kernel, which is then represented as an unsigned int. M54xx does just that for Coldfire: arch/m68k/include/asm/io_no.h: #define PCI_IO_PA 0xf800 /* Host physical address */ (used to set PCI BAR mappings, so matches your definition above). All other (MMU) m68k users of inb()/outb() apply an io_offset in the platform specific address translation: arch/m68k/include/asm/io_mm.h: #define q40_isa_io_base 0xff40 #define enec_isa_read_base 0xfffa #define enec_isa_write_base 0xfffb arch/m68k/include/asm/amigayle.h: #define GAYLE_IO(0xa2+zTwoBase) /* 16bit and even 8bit registers */ #define GAYLE_IO_8BITODD(0xa3+zTwoBase) /* odd 8bit registers */ (all constants used in address translation inlines that are used by the m68k inb()/outb() macros - you can call that the poor man's version of PCI BAR mappings ...). So as long as support for any of the m68k PCI or ISA bridges is selected in the kernel config, the appropriate IO space mapping is applied. If no support for PCI or ISA bridges is selected, we already fall back to zero offset mapping (but as far as I can tell, it shouldn't be possible to build a kernel without bridge support but drivers that require it). As this is indistinguishable from architectures that just don't have a base address for I/O ports (we unfortunately picked 0 as the default PCI_IOBASE value), my suggestion was to start marking architectures that may have this problem as using HAS_IOPORT in order to keep the existing behavior unchanged. If m68k does not suffer from this, making HAS_IOPORT conditional on those config options that actually need it would of course be best. Following your description, HAS_IOPORT would be required for neither of PCI, ISA or ATARI_ROM_ISA ?? Cheers, Michael Arnd ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
Hi Arnd, Am 01.01.2022 um 05:04 schrieb Arnd Bergmann: On Wed, Dec 29, 2021 at 10:44 PM Michael Schmitz wrote: Am 30.12.2021 um 14:48 schrieb Arnd Bergmann: On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz wrote: What some other architectures do is to rely on inb()/outb() to have a zero-based offset, and use an io_offset in PCI buses to ensure that a low port number on the bus gets translated into a pointer value for the virtual mapping in the kernel, which is then represented as an unsigned int. M54xx does just that for Coldfire: arch/m68k/include/asm/io_no.h: #define PCI_IO_PA 0xf800 /* Host physical address */ (used to set PCI BAR mappings, so matches your definition above). I think coldfire gets it right here, using PCI_IOBASE to find the start of the window and a zero io_offset: #define PCI_IOBASE ((void __iomem *) PCI_IO_PA) Good - I bear that in mind if I ever get around to reactivating my 060 accelerator and the PCI board for that. All other (MMU) m68k users of inb()/outb() apply an io_offset in the platform specific address translation: arch/m68k/include/asm/io_mm.h: #define q40_isa_io_base 0xff40 #define enec_isa_read_base 0xfffa #define enec_isa_write_base 0xfffb arch/m68k/include/asm/amigayle.h: #define GAYLE_IO(0xa2+zTwoBase) /* 16bit and even 8bit registers */ #define GAYLE_IO_8BITODD(0xa3+zTwoBase) /* odd 8bit registers */ (all constants used in address translation inlines that are used by the m68k inb()/outb() macros - you can call that the poor man's version of PCI BAR mappings ...). This still looks like the same thing to me, where you have inb() take a zero-based port number, not a pointer. The effect is the same as the coldfire version, it just uses a custom inline function instead of the version from asm-generic/io.h. Right. So as long as support for any of the m68k PCI or ISA bridges is selected in the kernel config, the appropriate IO space mapping is applied. If no support for PCI or ISA bridges is selected, we already fall back to zero offset mapping (but as far as I can tell, it shouldn't be possible to build a kernel without bridge support but drivers that require it). Right. As this is indistinguishable from architectures that just don't have a base address for I/O ports (we unfortunately picked 0 as the default PCI_IOBASE value), my suggestion was to start marking architectures that may have this problem as using HAS_IOPORT in order to keep the existing behavior unchanged. If m68k does not suffer from this, making HAS_IOPORT conditional on those config options that actually need it would of course be best. Following your description, HAS_IOPORT would be required for neither of PCI, ISA or ATARI_ROM_ISA ?? For these three options, we definitely need HAS_IOPORT, which would imply that some version of inb()/outb() is provided. The difference between Thanks for clarifying that (and to Niklas as well). Did sound a little counter-intuitive to me... using a custom PCI_IOBASE (or an open-coded equivalent) and using a zero PCI_IOBASE in combination with registering PCI using a custom io_offset is whether we can use drivers with hardcoded port numbers. These should depend on a different Kconfig symbol to be introduced (CONFIG_HARDCODED_IOPORT or similar) once we introduce them, and you could decide for m68k whether to allow those or not, I would assume you do want them in order to use certain legacy ISA drivers. That's exactly the purpose (though we're overmuch pushing the envelope trying to accomodate legacy ISA drivers on too many platforms). Cheers, Michael Arnd ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: (subset) [PATCH 00/17] -Wmissing-prototype warning fixes
Hi Martin, Arnd, On 25/08/23 13:12, Martin K. Petersen wrote: On Thu, 10 Aug 2023 16:19:18 +0200, Arnd Bergmann wrote: Most of the patches I sent so far for the -Wmissing-prototype warnings have made it into linux-next now. There are a few that I'm resending now as nobody has picked them up, and then a number of fixes that I found while test-building across all architectures rather than just the ones I usually test. The first 15 patches in this series should be uncontroversial, so I expect that either a subsystem maintainer or Andrew Morton can apply these directly. [...] Applied to 6.6/scsi-queue, thanks! [07/17] scsi: qlogicpti: mark qlogicpti_info() static https://git.kernel.org/mkp/scsi/c/71cc486335c4 [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? Cheers, Michael ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: (subset) [PATCH 00/17] -Wmissing-prototype warning fixes
Hi Geert,
Am 25.08.23 um 19:39 schrieb 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.
Thanks, that's good enough for me.
Linux 2.0 had this comment:
|/* * DMA transfer mask for GVP Series II SCSI controller. * Some
versions can only DMA into the 24 bit address space * (0->16M). Others
can DMA into the full 32 bit address * space. The default is to only
allow DMA into the 24 bit * address space. The "gvp11=0xFFFE" setup
parameter can * be supplied to force an alternate (32 bit) mask. */ |
|We now handle that (since 2.6.35) through masks defined in
gvp11_zorro_tbl[] (though I note these don't account for unaligned
addresses such as implied by the example in the comment. Are unaligned
DMA buffers still possible today?). Would that cover the 'A2000 with
accelerator' case?
|
||
I'm happy to send a patch if an override to the device default DMA mask
is still necessary.
(Incidentally - did you ever publish the m68k full history tree anywhere
in git?)
Cheers,
Michael
>
> Gr{oetje,eeting}s,
>
> Geert
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: (subset) [PATCH 00/17] -Wmissing-prototype warning fixes
Hi Geert,
Am 28.08.2023 um 18:42 schrieb 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?
The very same ...
No, and I should look into doing that...
No pressure!
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
