From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F5E63BBCB for ; Sat, 6 Apr 2024 15:27:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=139.178.84.217 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712417249; cv=none; b=EeraF7S/Kpr6sMpDfZDoYXep7YZC7Faimtc/O3oAu3NkETU0sCV/7TfTXntalO4NastEV7lc7uc9R3zuL4SAG1tgS3pKkV8xoJ/P9ZEpDA/vNOzfOsuXv0SAayEVLIQ0AX/USYBuOh+gzCjYuTVPbMy4st61OJvF9iJVqfFfjG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712417249; c=relaxed/simple; bh=2rySa9t9VCItK6MZJ9ubIFsysl4IsjaeTxE0EGK1V7Y=; h=MIME-Version:Message-Id:In-Reply-To:References:Date:From:To:Cc: Subject:Content-Type; b=aVldvK7eXp3RJ0FN4gnm5az3QEHV5y1WTHIDBWdlb9TCw2wPLecS/dXr53j4pAI20FEZ2PF+71fJB8lzZqtohrk1CqznN/3zAScAQkGestBlEGQytUDD/osqi+L2BQamwSl0kZG1BU4+csqjAEfncEfd1odAIp7BP3IEXb8vs9w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kernel.org; spf=pass smtp.mailfrom=kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EpEUpiap; arc=none smtp.client-ip=139.178.84.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EpEUpiap" Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6A2F660B73 for ; Sat, 6 Apr 2024 15:27:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B7CBC43394; Sat, 6 Apr 2024 15:27:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712417245; bh=2rySa9t9VCItK6MZJ9ubIFsysl4IsjaeTxE0EGK1V7Y=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=EpEUpiapYMNcn35KoFQr4r+T1mq/Xd3hUqTVaf8wQNm+LyGBNgGJSk6Jq+Zr+1FtM jJChI1nJUcSosMep32XCj8ED5WtTPxzXXmSafxBDhVv0U1VZwX02xQ+19aW9xBUaUA hCg42yKaJHuVBtE/AWkKBi0y6kdUWb/YwVAZx5JC90P38+OCekI1gaFlJoDV4cNRxg 8D9+0PnomvKXelAqBK8PSVmuXJt3GP3JEMm3HeUUl5762Y5c/3cV+BPeQs7c9fOsPX W5uk5ar3DohzQIgNGPmWdcryh7QKZ3c7l/sGEoygzsew9XGkNjj2dJbBS9gUxEYaCE 8imEslZThxkdQ== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfauth.nyi.internal (Postfix) with ESMTP id 8BF731200069; Sat, 6 Apr 2024 11:27:24 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute5.internal (MEProxy); Sat, 06 Apr 2024 11:27:24 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudegvddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusehkvghrnhgvlhdrohhrgheqnecuggftrf grthhtvghrnhepvdeviefgtedugeevieelvdfgveeuvdfgteegfeeiieejjeffgeeghedu gedtveehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghrnhguodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduvdekhedujedt vdegqddvkeejtddtvdeigedqrghrnhgupeepkhgvrhhnvghlrdhorhhgsegrrhhnuggsrd guvg X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CC89EB6008D; Sat, 6 Apr 2024 11:27:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542 Precedence: bulk X-Mailing-List: linux-m68k@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: In-Reply-To: References: <20240403122851.38808-1-schnelle@linux.ibm.com> <6b308ab0-dda7-4052-98b3-cb03e17e3e12@app.fastmail.com> Date: Sat, 06 Apr 2024 17:27:03 +0200 From: "Arnd Bergmann" To: "Michael Schmitz" , "Geert Uytterhoeven" Cc: "Niklas Schnelle" , linux-m68k@lists.linux-m68k.org, "Heiko Carstens" , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/1] m68k: Handle HAS_IOPORT dependencies Content-Type: text/plain 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. >> $ git grep -w 'define\sei_inb' >> drivers/net/ethernet/8390/8390.h:#define ei_inb(_p) inb(_p) >> drivers/net/ethernet/8390/8390p.c:#define ei_inb(_p) inb(_p) >> drivers/net/ethernet/8390/ax88796.c:#define ei_inb(_a) readb(ax_convert_addr(_a)) >> drivers/net/ethernet/8390/etherh.c:#define ei_inb(_p) readb((void __iomem *)_p) >> drivers/net/ethernet/8390/hydra.c:#define ei_inb(port) in_8(port) >> drivers/net/ethernet/8390/mac8390.c:#define ei_inb(port) in_8(port) >> drivers/net/ethernet/8390/mcf8390.c:#define ei_inb ei_inb >> drivers/net/ethernet/8390/xsurf100.c:#define ei_inb(_a) z_readb(ax_convert_addr(_a)) >> drivers/net/ethernet/8390/zorro8390.c:#define ei_inb(port) in_8(port) >> >> Can't apne.c just do the same here? The patch below didn't >> take that long to come up with, but I may be missing something >> here of course. > > The address translation from ISA IO ports to MMIO addresses needs to be > added as well (in_8() does not use address translation on m68k). Indeed, I totally missed that bit. > apne.c also uses inw() which does have a different address translation > yet, but that's only for data transfer from the ring buffers and can > be handled entirely inside apne.c. and this as well. > Now that is all limited to m68k. I might be able to submit a patch, but > I cannot test any of this. > > 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. 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. > 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. Arnd