[PATCH v4 0/2] Amiga RDB partition support fixes

Jens, as suggested, here's a new version of the Amiga RDB partition table patch. I've split off the part fixing the incorrect use of signed int for partition start address and size as separate patch. This change should be incontroversial (I hope). It does fix the bug that Martin Steigerwald

Re: m68k allmodconfig build errors

Hi Geert, Am 27.09.2018 um 18:48 schrieb Geert Uytterhoeven: Hi Michael, On Thu, Sep 27, 2018 at 7:01 AM Michael Schmitz wrote: as far as I can see, at least DM_PERSISTENT_DATA, DM_BIO_PRISON, DM_CACHE and DM_ERA all depend on dm_block_t which is defined as u64_t. These would also have

Re: m68k allmodconfig build errors

Tue, Sep 25, 2018 at 10:47 PM Michael Schmitz wrote: > > It's not just me - this happens when building without LBD support: > > > > ERROR: "__udivdi3" [drivers/md/dm-thin-pool.ko] undefined! > > > > Looks like DM_THIN_PROVISIONING should depend on LBD support be

Re: m68k allmodconfig build errors

Hi Geert, On 25/09/18 18:24, Geert Uytterhoeven wrote: Hi Michael, On Tue, Sep 25, 2018 at 1:23 AM Michael Schmitz wrote: Has this been resolved in the meantime? Not that I'm aware of. I'm running into a little dilemma when working on yet another spin on the RDB partition patch

Re: m68k allmodconfig build errors

Hi Geert, Am 25.09.2018 um 18:24 schrieb Geert Uytterhoeven: Hi Michael, On Tue, Sep 25, 2018 at 1:23 AM Michael Schmitz wrote: Has this been resolved in the meantime? Not that I'm aware of. I'm running into a little dilemma when working on yet another spin on the RDB partition patch

Re: m68k allmodconfig build errors

Hi Finn, On 25/09/18 11:49, Finn Thain wrote: On Tue, 25 Sep 2018, Michael Schmitz wrote: Hi Finn, has this been resolved in the meantime? My compiler is too old (4.4.6) to be affected. Also, I didn't pursue a patch because I don't really know how you fix this properly. Maybe Andreas

Re: m68k allmodconfig build errors

Hi Finn, has this been resolved in the meantime? I'm running into a little dilemma when working on yet another spin on the RDB partition patch (the patch that just won't die): either use old gcc 4.6.3, and lack __udivdi3 support, or new and shiny 8.10 with its strncmp mess. Cheers,    

Re: [PATCH 2/2] input: atakbd.c - fix Atari CapsLock behaviour

Torokhov wrote: On Mon, Sep 17, 2018 at 10:29:08PM +0200, Andreas Schwab wrote: On Sep 17 2018, Dmitry Torokhov wrote: On Fri, Sep 07, 2018 at 11:40:43AM +1200, Michael Schmitz wrote: The CapsLock key on Atari keyboards is not a toggle, it does send the normal make and break scancodes. Drop

Re: [PATCH RFC net-next] Amiga PCMCIA 100 MBit card support

Hi, I don't expect you to know the ultimate answer to this question - hoping Geert, as m68k kernel maintainer will voice an opinion. Having authored a little of the code in io_mm.h and raw_io.h, I know from experience how many pitfalls lie hidden in that file. On 17/09/18 06:05, ALeX Kazik

Re: [PATCH RFC net-next] Amiga PCMCIA 100 MBit card support

Thanks for your patch! [dropping netdev for discussion of m68k IO accessor details] Am 16.09.2018 um 08:40 schrieb ALeX Kazik: This adds an option to change the (10 MBit only) "apne" driver to support the 10/100 Mbit cards (e.g. Netgear FA411, CNet Singlepoint) instead. A new configure option

AztecMonster II SATA SCSI adapter

Hi All, anyone else on the lists who had trouble getting the AztecMonster II SATA SCSI adapter to work on Atari, or Mac or Sun3 (using the NCR5380 SCSI driver)? Trying to gauge whether it's worth the effort to add a workaround hack to the driver... Cheers, Michael

Re: [PATCH 1/2] input: atakbd.c - fix Atari keymap

Thanks Andreas! Cheers, Michael Am 07.09.2018 um 21:22 schrieb Andreas Schwab: Signed-off-by: Andreas Schwab Andreas.

[PATCH 2/2] input: atakbd.c - fix Atari CapsLock behaviour

The CapsLock key on Atari keyboards is not a toggle, it does send the normal make and break scancodes. Drop the CapsLock toggle handling code, which did cause the CapsLock key to merely act as a Shift key. Tested-by: Michael Schmitz Signed-off-by: Michael Schmitz --- drivers/input/keyboard

[PATCH 0/2] input: atakbd.c bug fixes

Two bug fixes for the Atari keyboard input driver: - keymap fixes: multiple keymap errors that had gone unnoticed since migration of the m68k keyboard driver code to the input framework. Correct the wrong keycodes - keymap is stil US but keypad, help and undo keys all generate the correct

[PATCH 1/2] input: atakbd.c - fix Atari keymap

From: Andreas Schwab Fix errors in Atari keymap (mostly in keypad, help and undo keys). Patch provided on debian-68k ML by Andreas Schwab , keymap array size and unhandled scancode limit adjusted to 0x73 by me. Tested-by: Michael Schmitz Signed-off-by: Michael Schmitz --- drivers/input

Re: [PATCH v4 00/11] macintosh: Resolve various PMU driver problems

No regressions on my PowerBook G4, so for this series: Tested-by: Michael Schmitz Am 02.07.2018 um 20:21 schrieb Finn Thain: This series of patches has the following aims. 1) Eliminate duplicated code. Linux presently has two drivers for the 68HC05-based PMU devices found in Macs: via-pmu

[PATCH v3] block: fix Amiga partition support for disks >= 1 TB

-by: Martin Steigerwald Message-ID: <201206192146.09327.mar...@lichtvoll.de> Signed-off-by: Michael Schmitz Tested-by: Martin Steigerwald --- Changes from RFC: - use u64 instead of sector_t, since that may be u32 without LBD support - check multiplication overflows each step - 3 u32 values may

Re: [PATCH] block: fix Amiga partition support for disks >= 1 TB

Hi Geert, Am 03.07.2018 um 19:22 schrieb Geert Uytterhoeven: Hi Michael, On Tue, Jul 3, 2018 at 1:58 AM Michael Schmitz wrote: On Mon, Jul 2, 2018 at 8:29 PM, Geert Uytterhoeven wrote: + + /* Warn user if start_sect or nr_sects overflow u32 */ + if ((nr_sects

[PATCH v2] block: fix Amiga partition support for disks >= 1 TB

-by: Martin Steigerwald Message-ID: <201206192146.09327.mar...@lichtvoll.de> Signed-off-by: Michael Schmitz Tested-by: Martin Steigerwald --- Changes from RFC: - use u64 instead of sector_t, since that may be u32 without LBD support - check multiplication overflows each step - 3 u32 values may

Re: [PATCH] block: fix Amiga partition support for disks >= 1 TB

Hi Geert, thanks for your comments! On Mon, Jul 2, 2018 at 8:29 PM, Geert Uytterhoeven wrote: > >> + /* CylBlocks is total number of blocks per cylinder */ >> + cylblk = be32_to_cpu(pb->pb_Environment[3]) * >> +

Re: [PATCH] block: fix Amiga partition support for disks >= 1 TB

Hi Kars, thanks for your comments - will do. Cheers, Michael On Mon, Jul 2, 2018 at 6:38 PM, Kars de Jong wrote: > Op ma 2 jul. 2018 om 07:29 schreef Michael Schmitz : >> @@ -98,6 +101,79 @@ int amiga_partition(struct parsed_partitions *state) >> if (checksu

[PATCH] block: fix Amiga partition support for disks >= 1 TB

-by: Martin Steigerwald Message-ID: <201206192146.09327.mar...@lichtvoll.de> Signed-off-by: Michael Schmitz Tested-by: Martin Steigerwald Changes from RFC: - use u64 instead of sector_t, since that may be u32 without LBD support - check multiplication overflows each step - 3 u32 values may exce

Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Martin, Am 30.06.18 um 19:49 schrieb Martin Steigerwald: > I am really inclined to point some AmigaOS 4 developers to this > discussion and just looked for an archive. Unfortunately there does not > appear to be a working one. The one mentioned on > > http://www.linux-m68k.org/mail.html > >

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 01.07.2018 um 09:10 schrieb Geert Uytterhoeven: Hi Michael, On Fri, Jun 29, 2018 at 11:12 AM Michael Schmitz wrote: Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven: On Wed, Jun 27, 2018 at 4:47 AM wrote: From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Joanne, Am 30.06.18 um 15:56 schrieb jdow: > > >>> As far as I can guess from the code, pb_Environment[3] (number of > >> heads) > >>> and pb_Environment[5] (number of sectors per cylinder) are abitrarily > >>> chosen so the partition size can be expressed as a difference between > >>>

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Joanne, Am 30.06.18 um 12:57 schrieb jdow: > On 20180629 17:44, Michael Schmitz wrote: > > > struct PartitionBlock { > >  __be32  pb_ID; > >  __be32  pb_SummedLongs; > >  __s32   pb_ChkSum; > >  __u32   pb_HostID; > >   

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Joanne, Am 30.06.18 um 11:24 schrieb jdow: > > On 20180629 14:45, Martin Steigerwald wrote: > > Beware: Essay ahead which proofs it to the point that there is no > > overflow in RDB before 96 bits maximum value of sectors: > > Time to go into more detail on RDBs. It isn't as simple as it started

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Martin, Am 30.06.18 um 09:24 schrieb Martin Steigerwald: > Hi Michael. > > Michael Schmitz - 29.06.18, 11:07: >>> But it's up to the person (which is not Linux) formatting the disk >>> to >>> not try to use >>> it on systems that cannot handle it,

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 29.06.18 um 21:12 schrieb Geert Uytterhoeven: > Hi Michael, > > On Fri, Jun 29, 2018 at 11:08 AM Michael Schmitz wrote: >> Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven: >>>> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 29.06.18 um 21:10 schrieb Geert Uytterhoeven: > >> The question is - can writes to the disk cause any damage to data on the >> disk, as seen by old OS versions? If the answer is no, we won't need the >> option after all. > You mean someone relying on the parameters of his RDB to

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven: > Hi Michael, > > Thanks for your patch! > > On Wed, Jun 27, 2018 at 4:47 AM wrote: >> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001 > ?? > >> The Amiga RDB partition parser module uses int for partition sector

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven: > Hi Michael, > >> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt >> to use it? > No idea... > > Probably some old Windows or MacOS versions will just suggest to > format your "new" disk ;-) Yep, that's what I'd

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 28.06.18 um 18:45 schrieb Geert Uytterhoeven: > Hi Michael, > > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote: >> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald: >>>>> And as stated in my other reply to the patch: >>>>&g

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Geert, Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven: > >>> Do we really need the warning? >>> Once the parsing is fixed doing 64-bit math, it does not matter for >>> Linux anymore. >> Well, irony of this is: In my case the RDB has been created on a machine >> with a native OS. So Linux

Re: moving affs + RDB partition support to staging?

. Amigoids screamed. I tried to tell them I was there, it was my machine, and 1.1 was, indeed, crap. {o.o} On 20180627 02:00, Michael Schmitz wrote: Joanne, I'm not at all allergic to avoiding RDB at all cost for new disks. If AmigaOS 4.1 supports more recent partition formats, all the better. T

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Martin, Am 28.06.2018 um 09:20 schrieb Martin Steigerwald: And as stated in my other reply to the patch: partition needs 64 bit disk device support in AmigaOS or AmigaOS like operating systems (NSD64, TD64 or SCSI direct) I'd probably leave it at 'disk needs 64 bit disk device support on

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

unds that such a partition would be misparses on legacy 32 bit >> systems (other than Linux). >> >> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43511 >> Reported-by: Martin Steigerwald >> Message-ID: <201206192146.09327.mar...@lichtvoll.de> >> Si

Re: Subject: [PATCH RFC] block: fix Amiga RDB partition support for disks >= 2 TB

Hi Martin, thanks for your comments. On Wed, Jun 27, 2018 at 8:24 PM, Martin Steigerwald wrote: > Thanks a lot again for your patch. > > schmitz...@gmail.com - 27.06.18, 03:24: >> + if (start_sect > INT_MAX || nr_sects > INT_MAX >> + || (start_sect +

Re: [PATCH v3 00/12] macintosh: Resolve various PMU driver problems

Gabriel, Am 27.06.2018 um 21:00 schrieb Gabriel Paubert: On Wed, Jun 27, 2018 at 05:39:15PM +1200, Michael Schmitz wrote: Ben, Am 27.06.2018 um 15:27 schrieb Benjamin Herrenschmidt: On Wed, 2018-06-27 at 13:08 +1000, Michael Ellerman wrote: I will rewrite patch 10/12 after Arnd's fixes

Re: moving affs + RDB partition support to staging?

oing otherwise is very poor form. {o.o} Joanne "Said enough, she has" Dow On 20180626 18:07, Michael Schmitz wrote: Joanne, As far as I have been able to test, the change is backwards compatible (RDB partitions from an old disk 80 GB disk are still recognized OK). That"s only bee

Re: [PATCH v3 00/12] macintosh: Resolve various PMU driver problems

Ben, Am 27.06.2018 um 15:27 schrieb Benjamin Herrenschmidt: On Wed, 2018-06-27 at 13:08 +1000, Michael Ellerman wrote: I will rewrite patch 10/12 after Arnd's fixes and this series have all made their way through both powerpc and m68k trees, and submit it separately. drivers/macintosh is

Re: moving affs + RDB partition support to staging?

ough to keep it working for > yourself. > > GPT is probably the right way to go. Preserve the ability to read RDBs for > legacy disks only. > > {^_^} > > > On 20180626 01:31, Michael Schmitz wrote: >> >> Joanne, >> >> I think we all agree that doing 32 b

Re: moving affs + RDB partition support to staging?

Hi Martin, Am 26.06.18 um 20:02 schrieb Martin Steigerwald: > Michael. > > Michael Schmitz - 26.06.18, 04:23: >> Joanne, >> >> Martin's boot log (including your patch) says: >> >> Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512) sdb1 >>

Re: moving affs + RDB partition support to staging?

p is not quite so bad. {^_-} > > Just be sure you are aware of all the ramifications when you make a > change. I remember thinking about this for awhile and then determining > I REALLY did not want to think about it as my brain was getting tied > into a gordian knot. > > {^_^} > > On

Re: moving affs + RDB partition support to staging?

19902322 bytes. But that wastes just a WHOLE LOT of disk in block maps. > Go up to 4096 or 8192. The latter is 35 TB. > > {^_^} > On 20180624 02:06, Martin Steigerwald wrote: >> >> Hi. >> >> Michael Schmitz - 27.04.18, 04:11: >>> >>> test results at https

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

to test this properly on). Cheers,     Michael Am 24.06.18 um 21:06 schrieb Martin Steigerwald: > Hi. > > Michael Schmitz - 27.04.18, 04:11: >> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511 >> indicate the RDB parser bug is fixed by the patch given there

Re: switch m68k to use the generic dma code

Christoph,, I haven't had a chance to test your generic DMA changes on the Amiga SCSI driver yet. May or may not happen in the next two weeks. Cheers, Michael On Thu, Jun 21, 2018 at 12:26 AM, Christoph Hellwig wrote: > On Wed, Jun 20, 2018 at 10:07:30PM +1000, Finn Thain wrote: >> Looks

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

Hi, On Tue, Jun 12, 2018 at 6:53 PM, Laurent Vivier wrote: > On 12/06/2018 01:47, Finn Thain wrote: >> On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote: > ... >> I don't know what the bootloader situation is, but it looks messy... >> http://nubus-pmac.sourceforge.net/#booters >> >> Laurent,

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

: > On Sun, 2018-06-10 at 21:12 +1200, Michael Schmitz wrote: >> Hi Geert, > > Top posting, sorry ... > > We are painting that bike shed with way too many coats.. > > We can keep the existing definitions, stick a comment on them stating > "obsolete" an

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

Hi Geert, Am 10.06.2018 um 20:29 schrieb Geert Uytterhoeven: Hi Finn, On Sat, Jun 9, 2018 at 2:20 PM Finn Thain wrote: Is this enum used by any user space code? If so, perhaps rather leave the PMU_68K_V1 in there to avoid upsetting that? It also changes the value of PMU_68K_V2, which is an

[PATCH 2/2] net-next: xsurf100: drop include of lib8390.c

(m68k)") Signed-off-by: Michael Schmitz --- drivers/net/ethernet/8390/xsurf100.c | 11 +-- 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/8390/xsurf100.c b/drivers/net/ethernet/8390/xsurf100.c index e2c9638..1c3e8d1 100644 --- a/drivers/net/eth

[PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook

: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)") Signed-off-by: Michael Schmitz --- drivers/net/ethernet/8390/ax88796.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/8390/ax88796.c b/drivers/net/ethernet/8390/ax887

[PATCH 0/2] net-next: cleanup use of lib8390.c code in xsurf100.c

As suggested by Geert, xsurf100.c really does not need to duplicate code from lib8390.c which is already part of ax88796.c, by including that file. All we need from lib8390.c in the xsurf100 block output function is one single function: ax_NS8390_init(). Export this symbol through a wrapper in

Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)

Hi Michael, Am 09.06.2018 um 21:15 schrieb Michael Karcher: Michael Schmitz schrieb: Hi Michael, actually, the the block_input / block_output functions were the reason I included the lib8390.c file. Except for xs100_write / xs100_read, they are a verbatim copy from ax88796.c I'm

Re: [RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c

Hi Geert, Am 10.06.2018 um 02:33 schrieb Geert Uytterhoeven: Hi Michael, On Sat, Jun 9, 2018 at 7:58 AM Michael Schmitz wrote: Now that ax88796.c exports the ax_NS8390_init() symbol, we can include 8390.h instead of lib8390.c, avoiding duplication of that function and killing a few compile

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

Hi Andreas, Am 09.06.2018 um 19:14 schrieb Andreas Schwab: On Jun 09 2018, Michael Schmitz wrote: Hi Finn, Am 08.06.2018 um 14:24 schrieb Finn Thain: Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU device found in those models was never supported by this driver

Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

, version 1 */ PMU_68K_V2, /* 68K PMU, version 2 */ }; Is this enum used by any user space code? If so, perhaps rather leave the PMU_68K_V1 in there to avoid upsetting that? Otherwise, Reviewed-by: Michael Schmitz Cheers, Michael -- To unsubscribe from this list

[RFC PATCH 1/2] net-next: ax88796: export ax_NS8390_init() hook

The block I/O code for the new X-Surf 100 ax88796 driver needs ax_NS8390_init() for error fixup in its block_output function. Export this function so we can lose the lib8380.c include in the X-Surf 100 driver. Signed-off-by: Michael Schmitz --- drivers/net/ethernet/8390/ax88796.c |2 ++ 1

[RFC PATCH 2/2] net-next: xsurf100: drop include of lib8390.c

Now that ax88796.c exports the ax_NS8390_init() symbol, we can include 8390.h instead of lib8390.c, avoiding duplication of that function and killing a few compile warnings in the bargain. Signed-off-by: Michael Schmitz --- drivers/net/ethernet/8390/xsurf100.c | 10 +++--- 1 files changed

[RFC PATCH 0/2] net-next: cleanup use of lib8390.c code in xsurf100.c

As suggested by Geert, xsurf100.c really does not need to duplicate code from lib8390.c which is already part of ax88796.c, by including that file. All we need from lib8390.c in the xsurf100 block output function is one single function: ax_NS8390_init(). Export this symbol in ax88796.c so the

Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)

Hi Michael, Am 08.06.2018 um 21:28 schrieb Michael Karcher: Let me add my 2 cents as main author of that code: ... actually, the the block_input / block_output functions were the reason I included the lib8390.c file. Except for xs100_write / xs100_read, they are a verbatim copy from

Re: [PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)

Hi Geert, Am 08.06.2018 um 02:36 schrieb Geert Uytterhoeven: Hi Michael, On Thu, Apr 19, 2018 at 4:05 AM, Michael Schmitz wrote: From: Michael Karcher Add platform device driver to populate the ax88796 platform data from information provided by the XSurf100 zorro device driver. The ax88796

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Finn, On Tue, May 29, 2018 at 5:38 PM, Finn Thain wrote: > I found some patches here, > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent.2 That's the most recent IIRC. Haven't begun looking at that yet - still stuck at

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Finn, Am 29.05.2018 um 14:15 schrieb Finn Thain: > > Since an arch gets to apply limits in the dma ops it implements, why would > arch code also have to set a limit in the form of default platform device > masks? Powerpc seems to be the only arch that does this. One of Christoph's recent

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

time. Just my $0.02 ... Cheers, MIchael On Mon, May 28, 2018 at 10:15 PM, Geert Uytterhoeven wrote: > On Mon, May 28, 2018 at 7:26 AM, Finn Thain > wrote: >> On Mon, 28 May 2018, Michael Schmitz wrote: >>> Am 27.05.2018 um 17:49 schrieb Finn Thain: >>> > On

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Finn, Am 27.05.2018 um 17:49 schrieb Finn Thain: > On Sun, 27 May 2018, Michael Schmitz wrote: > >> That should have fixed the warning already ... > > It's still not fixed (hence my "acked-by" for Geunter's patch). > Odd - does link

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Finn, was your patch to implement this in arch_setup_pdev_archdata() rejected? That should have fixed the warning already ... Am 27.05.2018 um 15:01 schrieb Finn Thain: > On Sat, 26 May 2018, Guenter Roeck wrote: > >> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no >>

Re: [RFC] m68k/mm - adjust VM area to be unmapped by gap size for __iounmap()

Hi Geert, Am 24.05.2018 um 22:02 schrieb Geert Uytterhoeven: >> I happen to have a few old kernel trees around that I can consult for >> a rough history, and 2.4.30 still has the comment while 2.6.18 or >> 2.6.19 lost it. > > Of course all historical git trees contain linear history, not the

Re: [RFC] m68k/mm - adjust VM area to be unmapped by gap size for __iounmap()

Hi Geert, see attached for the 2.4.30 version of kmap.c. Cheers, Michael Am 23.05.2018 um 19:44 schrieb Geert Uytterhoeven: > Hi Michael, > > On Tue, May 22, 2018 at 12:51 PM, Michael Schmitz <schmitz...@gmail.com> > wrote: >> Am 22.05.2018 um 20:18 sc

Re: [RFC] m68k/mm - adjust VM area to be unmapped by gap size for __iounmap()

Hi Geert, On Wed, May 23, 2018 at 7:44 PM, Geert Uytterhoeven wrote: >>> At first sight (and looking in full-history-linux git history), I see no >>> reason for the gap. I'd assume having a block with address and size aligned >>> to 256 KiB (which the caller already takes

Re: [RFC] m68k/mm - adjust VM area to be unmapped by gap size for __iounmap()

Hi Geert, Am 22.05.2018 um 20:18 schrieb Geert Uytterhoeven: > Hi Michael, > > On Mon, May 14, 2018 at 1:10 PM, Michael Schmitz <schmitz...@gmail.com> wrote: > > On kernels with 020/030 support ... > >> get_io_area leaves an IO_SIZE gap between mappings whic

[RFC] m68k/mm - adjust VM area to be unmapped by gap size for __iounmap()

but should work the same on 040/060 (the extra page tables cleared there would never have been set up anyway). Comment on whether the gap size should be considered in looking for a suitable address to place the next mapping in get_io_area() would be welcome. Signed-off-by: Michael Schmitz

Re: [parted-devel] Atari label false positives

Hi Adrian, Am 12.05.2018 um 23:24 schrieb John Paul Adrian Glaubitz: > On 05/12/2018 10:41 AM, Michael Schmitz wrote: >>>> Do you have a dump of the root sector (plus additional eventual >>>> extended >>>> partition root sector) from these bugs? >>&g

Re: [parted-devel] Atari label false positives

Hi Adrian, Am 12.05.2018 um 19:59 schrieb John Paul Adrian Glaubitz: > On 05/12/2018 01:17 AM, Michael Schmitz wrote: >> The link order in the kernel (atari before msdos) has not been chosen at >> random. The msdos partition format probe will always succeed on any >> valid

Re: [parted-devel] Atari label false positives

Hi Phillip, Am 12.05.2018 um 03:56 schrieb Phillip Susi: > On 5/11/2018 11:29 AM, John Paul Adrian Glaubitz wrote: >> Thanks for digging this up. I wasn't aware of this particular issue before >> and I agree, this needs to be addressed. I hope that I didn't cause too >> many DOS partitions to be

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, Am 11.05.2018 um 22:06 schrieb Finn Thain: >> You would have to be careful not to overwrite a pdev->dev.dma_mask and >> pdev->dev.dma_coherent_mask that might have been set in a platform >> device passed via platform_device_register here. Coldfire is the only >> m68k platform

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, Am 11.05.2018 um 17:28 schrieb Finn Thain: > On Fri, 11 May 2018, Michael Schmitz wrote: > >> >> I'm afraid using platform_device_register() (which you already use for >> the SCC devices) is the only option handling this on a per-device basis >> witho

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, Am 11.05.2018 um 15:28 schrieb Finn Thain: > On Fri, 11 May 2018, Michael Schmitz wrote: > >>>> Which begs the question: why can' you set up all Nubus bus devices' >>>> DMA masks in nubus_device_register(), or nubus_add_board()? >>> >>

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, On Fri, May 11, 2018 at 11:55 AM, Finn Thain wrote: >> > What's worse, if you do pass a dma_mask in struct >> > platform_device_info, you end up with this problem in >> > platform_device_register_full(): >> > >> > if (pdevinfo->dma_mask) { >> >

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Finn, On Thu, May 10, 2018 at 1:25 PM, Finn Thain wrote: > On Thu, 3 May 2018, Geert Uytterhoeven wrote: > >> >> Perhaps you can add a new helper >> (platform_device_register_simple_dma()?) that takes the DMA mask, too? [...] > To actually hoist the dma mask setup

Re: [PATCH] nubus: Unconditionally register bus type

Hi Greg, Am 08.05.2018 um 19:25 schrieb Greg Kroah-Hartman: > On Tue, May 08, 2018 at 09:07:27AM +0200, Geert Uytterhoeven wrote: >> Hi Greg, >> >> On Tue, May 8, 2018 at 9:00 AM, Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >>> On Mon,

Re: moving affs + RDB partition support to staging?

Martin, On Mon, May 7, 2018 at 7:08 PM, Martin Steigerwald <mar...@lichtvoll.de> wrote: > Michael Schmitz - 07.05.18, 04:40: >> Al, >> >> I don't think there is USB sticks with affs on them as yet. There >> isn't even USB host controller support for Amiga hardw

Re: moving affs + RDB partition support to staging?

Al, I don't think there is USB sticks with affs on them as yet. There isn't even USB host controller support for Amiga hardware (yet). Last I tried USB on m68k (Atari, 060 accelerator) the desktop experience was such that I'd rather not repeat that in a hurry (and that was a simple FAT USB

Re: [PATCH] nubus: Unconditionally register bus type

ostcore_initcall(). >> > > >> > > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> >> > > Reported-by: Michael Schmitz <schmitz...@gmail.com> >> > > Tested-by: Stan Johnson <user...@yahoo.com> >> > > Fixes: 7

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

Hi Geert, Am 04.05.2018 um 19:24 schrieb Geert Uytterhoeven: > Hi Michael, > >>> Yes, that would be useful. The other assumption could be that >>> platform devices always allow an all-0xff dma mask. >> >> That's not always true (Atari NCR5380 SCSI and floppy would use a 24 >> bit DMA mask). We

Re: [RFC] Fix BUG splat during nubus_driver_register()

Fair enough - your patch fixes the issue, that's what matters. FWIW: Tested-by: Michael Schmitz <schmitz...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [RFC] Fix BUG splat during nubus_driver_register()

for presence of /proc/nubus with this patch? Do you want an alternative patch tested (MACH_IS_MAC() test in nubus_driver_register() instead)? Cheers, Michael On Wed, May 2, 2018 at 5:42 PM, Michael Schmitz <schmitz...@gmail.com> wrote: > Hi Finn, > > I'll try that one - will require a ne

Re: [RFC] Fix BUG splat during nubus_driver_register()

Hi Finn, I'll try that one - will require a new kernel though, and I can't currently reach elgar by ssh... Quite confident this is the right way to fix the issue. Regarding zorro bus drivers - bus_register is called unconditionally from a core initcall for the Zorro bus code. I suppose it's

Re: [PATCH net 3/4] net/mac8390: Convert to nubus_driver

Hi Finn, this one seems to cause a regression when attempting to load the mac8390 driver on Amiga (Adrian just tried that): [ 16.36] kernel BUG at drivers/base/driver.c:151! [ 16.37] *** TRAP #7 *** FORMAT=0 [ 16.38] Current process id is 1 [ 16.39] BAD KERNEL TRAP:

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

Hi Geert, test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511 indicate the RDB parser bug is fixed by the patch given there, so if Martin now submits the patch, all should be well? (MSDOS partition support is not the only one with limitations - the SGI partition parser also uses

Re: [PATCH v4 00/10] New network driver for Amiga X-Surf 100 (m68k)

Thanks Dave! And many thanks to all the reviewers and testers! Cheers, Michael On Fri, Apr 20, 2018 at 8:11 AM, David Miller <da...@davemloft.net> wrote: > From: Michael Schmitz <schmitz...@gmail.com> > Date: Thu, 19 Apr 2018 14:05:17 +1200 > >> Thi

Re: [PATCH v4 00/10] New network driver for Amiga X-Surf 100 (m68k)

Hi, messed up the subject there, sorry - this was meant to be [PATCH v4 0/9] net-next: New network driver for Amiga X-Surf 100 (m68k) Cheers, Michael Am 19.04.2018 um 14:05 schrieb Michael Schmitz: > [This is a resend of my v3 series which was based on the wrong version and >

[PATCH v4 6/9] net-next: ax88796: add interrupt status callback to platform data

being compatible to the previous behaviour). Signed-off-by: Michael Karcher <ker...@mkarcher.dialup.fu-berlin.de> Signed-off-by: Michael Schmitz <schmitz...@gmail.com> --- drivers/net/ethernet/8390/ax88796.c | 23 +-- include/net/ax88796.h |5 + 2 files

[PATCH v4 00/10] New network driver for Amiga X-Surf 100 (m68k)

[This is a resend of my v3 series which was based on the wrong version and tree. Only substantial change is to Asix AX99796B PHY driver.] This patch series adds support for the Individual Computers X-Surf 100 network card for m68k Amiga, a network adapter based on the AX88796 chip set. The

[PATCH v4 8/9] net-next: ax88796: release platform device drvdata on probe error and module remove

The net device struct pointer is stored as platform device drvdata on module probe - clear the drvdata entry on probe fail there, as well as when unloading the module. Signed-off-by: Michael Schmitz <schmitz...@gmail.com> --- drivers/net/ethernet/8390/ax88796.c |2 ++ 1 files chan

[PATCH v4 1/9] net-next: phy: new Asix Electronics PHY driver

<and...@lunn.ch> Signed-off-by: Michael Schmitz <schmitz...@gmail.com> --- Changes in v4: Andrew Lunn: - don't duplicate genphy_soft_reset, just call after writing zero to control register --- drivers/net/phy/Kconfig |6 drivers/net/phy/Makefile |1 + drivers/ne

[PATCH v4 4/9] net-next: ax88796: Do not free IRQ in ax_remove() (already freed in ax_close()).

called to revert the effects of probe. Fixes: 82533ad9a1c (net: ethernet: ax88796: don't call free_irq without request_irq first) Signed-off-by: Michael Karcher <ker...@mkarcher.dialup.fu-berlin.de> Signed-off-by: Michael Schmitz <schmitz...@gmail.com> Reviewed-by: Geert Uytterhoeven <ge.

[PATCH v4 7/9] net-next: ax88796: set IRQF_SHARED flag when IRQ resource is marked as shareable

From: Michael Karcher <ker...@mkarcher.dialup.fu-berlin.de> On the Amiga X-Surf100, the network card interrupt is shared with many other interrupt sources, so requires the IRQF_SHARED flag to register. Signed-off-by: Michael Karcher <ker...@mkarcher.dialup.fu-berlin.de> Signed-off

[PATCH v4 9/9] net-next: New ax88796 platform driver for Amiga X-Surf 100 Zorro board (m68k)

r <ker...@mkarcher.dialup.fu-berlin.de> Signed-off-by: Michael Schmitz <schmitz...@gmail.com> --- Changes in v3: Suggested by Geert Uytterhoeven: - use ei_local->reset_8390() instead of duplicating ax_reset_8390() - use %pR to format struct resource pointers - assign pd

[PATCH v4 3/9] net-next: ax88796: Attach MII bus only when open

r <ker...@mkarcher.dialup.fu-berlin.de> Signed-off-by: Michael Schmitz <schmitz...@gmail.com> Reviewed-by: Andrew Lunn <and...@lunn.ch> --- drivers/net/ethernet/8390/ax88796.c | 183 ++- 1 files changed, 95 insertions(+), 88 deletions(-) diff --git a/drivers/n

<    1   2   3   4   5   6   7   8   >