mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Arnd Bergmann <arnd@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	linux-m68k@lists.linux-m68k.org,
	Heiko Carstens <hca@linux.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] m68k: Handle HAS_IOPORT dependencies
Date: Sun, 7 Apr 2024 08:09:10 +1200	[thread overview]
Message-ID: <d70568b7-121b-886f-f6d7-ef6e5db2ca50@gmail.com> (raw)
In-Reply-To: <a5bca6fc-1720-45cf-8cf3-3f129e699d79@app.fastmail.com>

Hi Arnd,

Am 07.04.2024 um 03:27 schrieb Arnd Bergmann:
> On Sat, Apr 6, 2024, at 03:14, Michael Schmitz wrote:
>> Am 06.04.2024 um 09:13 schrieb Arnd Bergmann:
>>> On Fri, Apr 5, 2024, at 20:36, Michael Schmitz wrote:
>>>> Am 05.04.2024 um 23:16 schrieb Geert Uytterhoeven:
>>>> The last time I tried to add support for a different PCMCIA ethernet
>>>> adapter to apne.c _without_ adding to the hacks in io_mm.h, I wasn't
>>>> getting anywhere with the netdev crowd. That was ages ago, and I doubt
>>>> their enthusiasm for a rewrite of the 8390 code base to avoid using
>>>> inb() on MMIO architectures will be any better now.
>>>
>>> From what I can see, there is already an abstraction layer in
>>> these drivers that is used by all m68k drivers except apne:
>>
>> As well as ne ... which uses the 8390p.c helper.
>
> Is there any machine using ne.c that doesn't set HAS_IOPORT though?
> Q40 and ATARI_ETHERNEC both have custom inb()/outb(), so
> those are not affected by the change.

Thanks for clarifying - I had been left with the impression that 
inb()/outb() would only be retained for architectures that have not only 
the ISA bus but inb/outb processor instructions.

>> ne.c needs the same treatment as far as I can see, and I could actually
>> test that one (on Atari, not actually on a PC ISA card). I'll see what I
>> can come up with.
>
> ATARI_ROM_ISA turns on HAS_IOPORT, so this one doesn't need any
> immediate changes as a result of Niklas's series. I see now that
> the apne driver doesn't actually need changes either since
> AMIGA_PCMCIA turns on ISA.

Your patch would not actually be too hard to get right as apne only 
needs unconditional address translation (unless we want to take this 
opportunity to introduce 100 Mbit support; I need to dig out my old 
patches for that). But perhaps leave that for later

> I don't think there is an easy way to rework ne.c to avoid
> inb()/outb(), but you could consider splitting the atari
> support out into a separate module the same way as apne.c
> to make it use the atari operations directly.

We used to have atari_ethernec.c for that. AFAIR the netdev maintainers 
asked for us to use ne.c instead. They had suggestions around making IO 
abstractions more flexible for apne.c a while back. I need to revisit that.

>> I might well be missing something else here - as I said, it's been a few
>> years since I worked on the apne driver, and experimented with IO
>> abstractions in that context. The problem has always been making sure
>> drivers shared by different m68k platforms need only be built once and
>> still work on e.g. Q40 and Atari.
>
> Do you know of any other ISA style drivers that are used with the
> amiga pcmcia or the atari rom I/O operations, aside from the 8390
> family? If this is the only one using it, it does sound like this
> could be simplified a lot by just making those two not share the
> object code with the ISA-style ne.c.

No network drivers that I can remember, but the same ROM I/O is used by 
the isp116x-hcd USB driver. That one uses the defines from asm/raw_io.h 
directly though, not inb()/outb().

I don't think any other PCMCIA cards were ever supported on Amiga.

Cheers,

	Michael

>
>       Arnd
>

  reply	other threads:[~2024-04-06 20:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 12:28 Niklas Schnelle
2024-04-03 12:28 ` [PATCH 1/1] m68k: Let GENERIC_IOMAP depend on HAS_IOPORT Niklas Schnelle
2024-05-08 11:44   ` Geert Uytterhoeven
2024-04-03 18:11 ` [PATCH 0/1] m68k: Handle HAS_IOPORT dependencies Michael Schmitz
2024-04-03 18:34   ` Arnd Bergmann
2024-04-05 10:16     ` Geert Uytterhoeven
2024-04-05 11:24       ` Arnd Bergmann
2024-04-08  8:23         ` Geert Uytterhoeven
2024-04-05 18:36       ` Michael Schmitz
2024-04-05 20:13         ` Arnd Bergmann
2024-04-06  1:14           ` Michael Schmitz
2024-04-06 15:27             ` Arnd Bergmann
2024-04-06 20:09               ` Michael Schmitz [this message]
2024-04-08  8:19         ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d70568b7-121b-886f-f6d7-ef6e5db2ca50@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=arnd@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=hca@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=schnelle@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®