From: Arnd Bergmann <arnd@arndb.de>

Based on some recent discussions [1][2][3], I experimented wtih what
drivers/pcmcia would look like if we completely removed 16-bit support,
which was one of the options that Dominik suggested for winding down
pcmcia maintenance.

The remaining cardbus/yenta support is essentially a PCI hotplug driver
with a slightly unusual sysfs interface, and it would still support all
32-bit cardbus hosts and cards, but no longer work with the even older
16-bit cards that require the pcmcia_driver infrastructure.

I don't expect this to be a problem normal laptop support, as the last
PC models that predate Cardbus support (e.g. 1997 ThinkPad 380ED) are
all limited to i586MMX CPUs and 80MB of RAM. This is barely enough to
boot Tiny Core Linux but not a regular distro.

Support for device drivers is somewhat less clear. Losing support for
16-bit cards in cardbus sockets is obviously a limiting factor for
anyone who still has those cards, but there is also a good chance that
the only reason to keep the cards around is for using them in pre-cardbus
machines that cannot be upgrade to 32-bit devices.

Completely removing the 16-bit PCMCIA support would however break some
20+ year old embedded machines that rely on CompactFlash cards as their
mass-storage device (extension), this notably includes early PocketPC
models and the reference implementations for OMAP1, StrongARM1100,
Alchemy and PA-Semi. All of these are still maintained, though most
of the PocketPC machines got removed in the 6.3 merge window and the
PA-Semi Electra board is the only one that was introduced after
2003.

The approach that I take in this series is to split drivers/pcmcia
into two mutually incompatible parts: the Cardbus support contains
all the code that is relevant for post-1997 laptops and gets moved
to drivers/pci/hotplug, while the drivers/pcmcia/ subsystem is
retained for both the older laptops and the embedded systems but no
longer works with the yenta socket host driver. The BCM63xx
PCMCIA/Cardbus host driver appears to be unused and conflicts with
this series, so it is removed in the process.

My series does not touch any of the pcmcia_driver instances, but
if there is consensus about splitting out the cardbus support,
a lot of them can probably get removed as a follow-up.

[1] https://lore.kernel.org/all/Y07d7rMvd5++85BJ@owl.dominikbrodowski.net/
[2] https://lore.kernel.org/all/c5b39544-a4fb-4796-a046-0b9be9853787@app.fastmail.com/
[3] https://lore.kernel.org/all/20230222092302.6348-1-jirislaby@kernel.org/

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Kevin Cernekee <cernekee@gmail.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Manuel Lauss <manuel.lauss@gmail.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Olof Johansson <olof@lixom.net>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: YOKOTA Hiroshi <yokota@netlab.is.tsukuba.ac.jp>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-can@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org

Arnd Bergmann (6):
  pccard: remove bcm63xx socket driver
  pccard: split cardbus support from pcmcia
  yenta_socket: copy pccard core code into driver
  yenta_socket: remove dead code
  pccard: drop remnants of cardbus support
  pci: hotplug: move cardbus code from drivers/pcmcia

 arch/mips/bcm63xx/Makefile                    |    2 +-
 arch/mips/bcm63xx/boards/board_bcm963xx.c     |   14 -
 arch/mips/bcm63xx/dev-pcmcia.c                |  144 -
 arch/mips/configs/bcm63xx_defconfig           |    1 -
 .../asm/mach-bcm63xx/bcm63xx_dev_pcmcia.h     |   14 -
 arch/mips/pci/ops-bcm63xx.c                   |  294 --
 arch/mips/pci/pci-bcm63xx.c                   |   44 -
 drivers/Makefile                              |    2 +-
 drivers/pci/hotplug/Kconfig                   |   56 +
 drivers/pci/hotplug/Makefile                  |    1 +
 drivers/pci/hotplug/yenta_socket.c            | 4056 +++++++++++++++++
 drivers/pcmcia/Kconfig                        |   63 +-
 drivers/pcmcia/Makefile                       |   13 +-
 drivers/pcmcia/bcm63xx_pcmcia.c               |  538 ---
 drivers/pcmcia/bcm63xx_pcmcia.h               |   61 -
 drivers/pcmcia/cardbus.c                      |  124 -
 drivers/pcmcia/cistpl.c                       |   10 +-
 drivers/pcmcia/cs.c                           |  103 +-
 drivers/pcmcia/cs_internal.h                  |   10 +-
 drivers/pcmcia/ds.c                           |   14 +-
 drivers/pcmcia/i82092.c                       |    2 +-
 drivers/pcmcia/i82365.c                       |    2 +-
 drivers/pcmcia/o2micro.h                      |  183 -
 drivers/pcmcia/pd6729.c                       |    3 +-
 drivers/pcmcia/ricoh.h                        |  169 -
 drivers/pcmcia/socket_sysfs.c                 |    2 -
 drivers/pcmcia/ti113x.h                       |  978 ----
 drivers/pcmcia/topic.h                        |  168 -
 drivers/pcmcia/yenta_socket.c                 | 1455 ------
 drivers/pcmcia/yenta_socket.h                 |  136 -
 {drivers => include}/pcmcia/i82365.h          |    0
 include/pcmcia/ss.h                           |   21 -
 32 files changed, 4147 insertions(+), 4536 deletions(-)
 delete mode 100644 arch/mips/bcm63xx/dev-pcmcia.c
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/bcm63xx_dev_pcmcia.h
 create mode 100644 drivers/pci/hotplug/yenta_socket.c
 delete mode 100644 drivers/pcmcia/bcm63xx_pcmcia.c
 delete mode 100644 drivers/pcmcia/bcm63xx_pcmcia.h
 delete mode 100644 drivers/pcmcia/cardbus.c
 delete mode 100644 drivers/pcmcia/o2micro.h
 delete mode 100644 drivers/pcmcia/ti113x.h
 delete mode 100644 drivers/pcmcia/topic.h
 delete mode 100644 drivers/pcmcia/yenta_socket.c
 delete mode 100644 drivers/pcmcia/yenta_socket.h
 rename {drivers => include}/pcmcia/i82365.h (100%)

-- 
2.39.2

On 2/27/23 07:34, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Based on some recent discussions [1][2][3], I experimented wtih what
> drivers/pcmcia would look like if we completely removed 16-bit support,
> which was one of the options that Dominik suggested for winding down
> pcmcia maintenance.
> 
> The remaining cardbus/yenta support is essentially a PCI hotplug driver
> with a slightly unusual sysfs interface, and it would still support all
> 32-bit cardbus hosts and cards, but no longer work with the even older
> 16-bit cards that require the pcmcia_driver infrastructure.
> 
> I don't expect this to be a problem normal laptop support, as the last
> PC models that predate Cardbus support (e.g. 1997 ThinkPad 380ED) are
> all limited to i586MMX CPUs and 80MB of RAM. This is barely enough to
> boot Tiny Core Linux but not a regular distro.
> 
> Support for device drivers is somewhat less clear. Losing support for
> 16-bit cards in cardbus sockets is obviously a limiting factor for
> anyone who still has those cards, but there is also a good chance that
> the only reason to keep the cards around is for using them in pre-cardbus
> machines that cannot be upgrade to 32-bit devices.
> 
> Completely removing the 16-bit PCMCIA support would however break some
> 20+ year old embedded machines that rely on CompactFlash cards as their
> mass-storage device (extension), this notably includes early PocketPC
> models and the reference implementations for OMAP1, StrongARM1100,
> Alchemy and PA-Semi. All of these are still maintained, though most
> of the PocketPC machines got removed in the 6.3 merge window and the
> PA-Semi Electra board is the only one that was introduced after
> 2003.
> 
> The approach that I take in this series is to split drivers/pcmcia
> into two mutually incompatible parts: the Cardbus support contains
> all the code that is relevant for post-1997 laptops and gets moved
> to drivers/pci/hotplug, while the drivers/pcmcia/ subsystem is
> retained for both the older laptops and the embedded systems but no
> longer works with the yenta socket host driver. The BCM63xx
> PCMCIA/Cardbus host driver appears to be unused and conflicts with
> this series, so it is removed in the process.
> 
> My series does not touch any of the pcmcia_driver instances, but
> if there is consensus about splitting out the cardbus support,
> a lot of them can probably get removed as a follow-up.

Arnd,

Your patch set also breaks my PowerBook G4. The output of 'lspci -nn | grep 
Network' shows the following before your patch is applied:

0001:10:12.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4306 
802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
0001:11:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4318 
[AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)

The first of these is broken and built into the laptop. The second is plugged 
into a PCMCIA slot, and uses yenta-socket as a driver.

When your patches are applied, the second entry vanishes.

Yes, this hardware is ancient, but I would prefer having this wifi interface 
work. I can provide any output you need.

Larry

On Mon, Feb 27, 2023, at 21:23, Larry Finger wrote:
> On 2/27/23 07:34, Arnd Bergmann wrote:

>
> Your patch set also breaks my PowerBook G4. The output of 'lspci -nn | grep 
> Network' shows the following before your patch is applied:
>
> 0001:10:12.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4306 
> 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
> 0001:11:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4318 
> [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
>
> The first of these is broken and built into the laptop. The second is plugged 
> into a PCMCIA slot, and uses yenta-socket as a driver.
>
> When your patches are applied, the second entry vanishes.
>
> Yes, this hardware is ancient, but I would prefer having this wifi interface 
> work. I can provide any output you need.

Is this the Cardbus or the PCMCIA version of the BCM4306 device? As far
as I understand this particular chip can be wired up either way inside
of the card, and the PowerBook G4 supports both types of devices.

If it's the PCMCIA version, then dropping support for it was the idea
of the patch series that we can debate, but if it was the Cardbus version
that broke, then this was likely a bug I introduced by accident.

      Arnd

On 2/27/23 14:38, Arnd Bergmann wrote:
> Is this the Cardbus or the PCMCIA version of the BCM4306 device? As far
> as I understand this particular chip can be wired up either way inside
> of the card, and the PowerBook G4 supports both types of devices.
> 
> If it's the PCMCIA version, then dropping support for it was the idea
> of the patch series that we can debate, but if it was the Cardbus version
> that broke, then this was likely a bug I introduced by accident.

Arnd,

The BCM4306 is internal, and wired directly to the PCI bus. My understanding is 
that the BCM4318 is a cardbus device. It definitely shows up in an lspci scan.

Larry

On Mon, Feb 27, 2023, at 22:09, Larry Finger wrote:
> On 2/27/23 14:38, Arnd Bergmann wrote:
>> Is this the Cardbus or the PCMCIA version of the BCM4306 device? As far
>> as I understand this particular chip can be wired up either way inside
>> of the card, and the PowerBook G4 supports both types of devices.
>> 
>> If it's the PCMCIA version, then dropping support for it was the idea
>> of the patch series that we can debate, but if it was the Cardbus version
>> that broke, then this was likely a bug I introduced by accident.
>
> The BCM4306 is internal, and wired directly to the PCI bus. My understanding is 
> that the BCM4318 is a cardbus device. It definitely shows up in an lspci scan.

Ah right, I got confused because I had googled for BCM4306 for too long
trying to find out whether that might be used in combination with the
BCM63xx SoC support that patch 1 removed.

BCM4318 should definitely keep working after my series. My best guess
is that the problem is that I introduced an unnecessary dependency
between CONFIG_CARDBUS and CONFIG_PCI_HOTPLUG, so you'd need to
either undo the dependency or enable both in the local config.

If it's not that, then it's a bug in my changes that needs to be
fixed before they can be considered for integration. As long as
we are still debating whether the series makes sense at all,
I'm not worried about this.

      Arnd

On 2/27/23 15:30, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 22:09, Larry Finger wrote:
>> On 2/27/23 14:38, Arnd Bergmann wrote:
>>> Is this the Cardbus or the PCMCIA version of the BCM4306 device? As far
>>> as I understand this particular chip can be wired up either way inside
>>> of the card, and the PowerBook G4 supports both types of devices.
>>>
>>> If it's the PCMCIA version, then dropping support for it was the idea
>>> of the patch series that we can debate, but if it was the Cardbus version
>>> that broke, then this was likely a bug I introduced by accident.
>>
>> The BCM4306 is internal, and wired directly to the PCI bus. My understanding is
>> that the BCM4318 is a cardbus device. It definitely shows up in an lspci scan.
> 
> Ah right, I got confused because I had googled for BCM4306 for too long
> trying to find out whether that might be used in combination with the
> BCM63xx SoC support that patch 1 removed.
> 
> BCM4318 should definitely keep working after my series. My best guess
> is that the problem is that I introduced an unnecessary dependency
> between CONFIG_CARDBUS and CONFIG_PCI_HOTPLUG, so you'd need to
> either undo the dependency or enable both in the local config.
> 
> If it's not that, then it's a bug in my changes that needs to be
> fixed before they can be considered for integration. As long as
> we are still debating whether the series makes sense at all,
> I'm not worried about this.

Arnd,

It was a configuration problem. In the .config obtained by installing your 
patches, and doing a make, CONFIG_CARDBUS was not mentioned, and 
CONFIG_PCI_HOTPLUG was not selected. When I deleted the reference to the latter, 
did a make, and set ..._HOTPLUG, I got CONFIG+CARDBUS set to "m", and the yenta 
modules were built. This version sees the BCM4318 in the lspci scan, and the 
interface works. Your patches are OK.

I am not sure how to warn people about the configuration change possible 
breaking things.

Larry

On Tue, Feb 28, 2023, at 04:57, Larry Finger wrote:
> On 2/27/23 15:30, Arnd Bergmann wrote:
>
> It was a configuration problem. In the .config obtained by installing 
> your 
> patches, and doing a make, CONFIG_CARDBUS was not mentioned, and 
> CONFIG_PCI_HOTPLUG was not selected. When I deleted the reference to 
> the latter, 
> did a make, and set ..._HOTPLUG, I got CONFIG+CARDBUS set to "m", and 
> the yenta 
> modules were built. This version sees the BCM4318 in the lspci scan, 
> and the 
> interface works. Your patches are OK.

Ok, great, thanks for testing!

> I am not sure how to warn people about the configuration change possible 
> breaking things.

My intention was to keep Cardbus support working with old defconfig files,
and I've not moved CONFIG_CARDBUS into a separate submenu between
CONFIG_PCI_HOTPLUG and CONFIG_PCI_CONTROLLER but left the driver in
drivers/pci/hotplug. I think that's the best compromise here, but maybe
the PCI maintainers have a better idea.

     Arnd

On 2/28/23 02:37, Arnd Bergmann wrote:
> My intention was to keep Cardbus support working with old defconfig files,
> and I've not moved CONFIG_CARDBUS into a separate submenu between
> CONFIG_PCI_HOTPLUG and CONFIG_PCI_CONTROLLER but left the driver in
> drivers/pci/hotplug. I think that's the best compromise here, but maybe
> the PCI maintainers have a better idea.

Arnd,

I did a bit more investigation. My original .config had CONFIG_PCI_HOTPLUG not 
defined, but did have CONFIG_CARDBUS and the various yenta modules turned on. 
With your changes, the CONFIG_PCI_HOTPLUG overrode CARDBUS.

I thought mine was a corner case, but now I am not sure. As stated above, the 
Debian 12 factory configuration for ppc32 does not turn on PCI hotplug, but the 
x86_64 configuration for openSUSE Tumbleweed does. The x86_64 configuration in 
Fedora 37 does not contain CONFIG_PCI_HOTPLUG, but does have CARDBUS set.

It seems that several distros may get the wrong result with this change,

Larry

On Wed, Mar 1, 2023, at 02:13, Larry Finger wrote:
> On 2/28/23 02:37, Arnd Bergmann wrote:
>> My intention was to keep Cardbus support working with old defconfig files,
>> and I've not moved CONFIG_CARDBUS into a separate submenu between
>> CONFIG_PCI_HOTPLUG and CONFIG_PCI_CONTROLLER but left the driver in
>> drivers/pci/hotplug. I think that's the best compromise here, but maybe
>> the PCI maintainers have a better idea.
>
> I did a bit more investigation. My original .config had CONFIG_PCI_HOTPLUG not 
> defined, but did have CONFIG_CARDBUS and the various yenta modules turned on. 
> With your changes, the CONFIG_PCI_HOTPLUG overrode CARDBUS.
>
> I thought mine was a corner case, but now I am not sure. As stated above, the 
> Debian 12 factory configuration for ppc32 does not turn on PCI hotplug, but the 
> x86_64 configuration for openSUSE Tumbleweed does. The x86_64 configuration in 
> Fedora 37 does not contain CONFIG_PCI_HOTPLUG, but does have CARDBUS set.
>
> It seems that several distros may get the wrong result with this change,

As far as I can tell, this should work with the changes I described
above, since CONFIG_CARDBUS no longer depends on CONFIG_PCI_HOTPLUG.
I now uploaded the changed version to

https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=pccard-rework-2

    Arnd

On Mon, Feb 27, 2023 at 09:38:54PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 21:23, Larry Finger wrote:
> > On 2/27/23 07:34, Arnd Bergmann wrote:
> 
> >
> > Your patch set also breaks my PowerBook G4. The output of 'lspci -nn | grep 
> > Network' shows the following before your patch is applied:
> >
> > 0001:10:12.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4306 
> > 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
> > 0001:11:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4318 
> > [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)
> >
> > The first of these is broken and built into the laptop. The second is plugged 
> > into a PCMCIA slot, and uses yenta-socket as a driver.
> >
> > When your patches are applied, the second entry vanishes.
> >
> > Yes, this hardware is ancient, but I would prefer having this wifi interface 
> > work. I can provide any output you need.
> 
> Is this the Cardbus or the PCMCIA version of the BCM4306 device? As far
> as I understand this particular chip can be wired up either way inside
> of the card, and the PowerBook G4 supports both types of devices.
> 
> If it's the PCMCIA version, then dropping support for it was the idea
> of the patch series that we can debate, but if it was the Cardbus version
> that broke, then this was likely a bug I introduced by accident.

If it shows up as a PCI device, it will be cardbus, not 16-bit ISA.

PCMCIA cards don't show up in lspci.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

On Mon, Feb 27, 2023 at 02:34:51PM +0100, Arnd Bergmann wrote:
> I don't expect this to be a problem normal laptop support, as the last
> PC models that predate Cardbus support (e.g. 1997 ThinkPad 380ED) are
> all limited to i586MMX CPUs and 80MB of RAM. This is barely enough to
> boot Tiny Core Linux but not a regular distro.

Am I understanding that the argument you're putting forward here is
"cardbus started in year X, so from year X we can ignore 16-bit
PCMCIA support" ?

Given that PCMCIA support has been present in x86 hardware at least
up to 2010, I don't see how that is any basis for making a decision
about 16-bit PCMCIA support.

Isn't the relevant factor here whether 16-bit PCMCIA cards are still
in use on hardware that can run a modern distro? (And yes, x86
machines that have 16-bit PCMCIA can still run Debian Stable today.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

From: Russell King
> Sent: 27 February 2023 20:16
> 
> On Mon, Feb 27, 2023 at 02:34:51PM +0100, Arnd Bergmann wrote:
> > I don't expect this to be a problem normal laptop support, as the last
> > PC models that predate Cardbus support (e.g. 1997 ThinkPad 380ED) are
> > all limited to i586MMX CPUs and 80MB of RAM. This is barely enough to
> > boot Tiny Core Linux but not a regular distro.
> 
> Am I understanding that the argument you're putting forward here is
> "cardbus started in year X, so from year X we can ignore 16-bit
> PCMCIA support" ?
> 
> Given that PCMCIA support has been present in x86 hardware at least
> up to 2010, I don't see how that is any basis for making a decision
> about 16-bit PCMCIA support.
> 
> Isn't the relevant factor here whether 16-bit PCMCIA cards are still
> in use on hardware that can run a modern distro? (And yes, x86
> machines that have 16-bit PCMCIA can still run Debian Stable today.)

Or, more specifically, are any people using 16-bit PCMCIA cards
in cardbus-capable sockets with a current kernel.
They might be using unusual cards that aren't available as
cardbus - perhaps 56k modems (does anyone still use those?).

I'm pretty sure I've used sparc systems that had slots that
would take both pcmcia and cardbus cards.
Would have been 20 years ago - but they were 64MHz PCI so wouldn't
have been that slow (I can't remember which cpu it was).
They ran Solaris, but weren't made by Sun.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From: David Laight
> Sent: 28 February 2023 22:45
...
> Or, more specifically, are any people using 16-bit PCMCIA cards
> in cardbus-capable sockets with a current kernel.
> They might be using unusual cards that aren't available as
> cardbus - perhaps 56k modems (does anyone still use those?).

Or, what I now remember we were doing:
Copying images to linear pcmcia sram cards to access from
an embedded system that only supported pcmcia.
(Which means the sparc systems supported both cardbus and pcmcia.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Mon, Feb 27, 2023, at 21:15, Russell King (Oracle) wrote:
> On Mon, Feb 27, 2023 at 02:34:51PM +0100, Arnd Bergmann wrote:
>> I don't expect this to be a problem normal laptop support, as the last
>> PC models that predate Cardbus support (e.g. 1997 ThinkPad 380ED) are
>> all limited to i586MMX CPUs and 80MB of RAM. This is barely enough to
>> boot Tiny Core Linux but not a regular distro.
>
> Am I understanding that the argument you're putting forward here is
> "cardbus started in year X, so from year X we can ignore 16-bit
> PCMCIA support" ?

Right, but I'm asking this as a question, hence the
'RFC' in the subject.

> Given that PCMCIA support has been present in x86 hardware at least
> up to 2010, I don't see how that is any basis for making a decision
> about 16-bit PCMCIA support.

I assume you mean machines with Cardbus slots that can use
16-bit PCMCIA slots, rather than laptops with only PCMCIA here,
right?

> Isn't the relevant factor here whether 16-bit PCMCIA cards are still
> in use on hardware that can run a modern distro? (And yes, x86
> machines that have 16-bit PCMCIA can still run Debian Stable today.)

There are three combinations that are supported at the moment:

1. Machines with only 16-bit PCMCIA support, all very old,
   which rely on these slots for basic functionality.
2. Machines that support Cardbus slots that are actually
   used to connect 16-bit cards.
3. Machines that have a Cardbus slot and can just use 32-bit
   cards for whatever they need.

Dominik originally raised the question whether we could
kill off all PCMCIA support already given its age, which
would either break all three of the above or at least
the first two if Yenta-socket is kept as a PCI hotplug
driver.

I wanted to make sure that we keep both case 1) for
sa1100/omap1/pxa and case 3) for x86, while case 2) seems
much less important because there are presumably fewer
users than 3), and they have an upgrade path that only
involves replacing one cheap card instead of trashing the
whole machine.

   Arnd

On Monday 27 February 2023 14:34:51 Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Based on some recent discussions [1][2][3], I experimented wtih what
> drivers/pcmcia would look like if we completely removed 16-bit support,
> which was one of the options that Dominik suggested for winding down
> pcmcia maintenance.
> 
> The remaining cardbus/yenta support is essentially a PCI hotplug driver
> with a slightly unusual sysfs interface, and it would still support all
> 32-bit cardbus hosts and cards, but no longer work with the even older
> 16-bit cards that require the pcmcia_driver infrastructure.
> 
> I don't expect this to be a problem normal laptop support, as the last
> PC models that predate Cardbus support (e.g. 1997 ThinkPad 380ED) are
> all limited to i586MMX CPUs and 80MB of RAM. This is barely enough to
> boot Tiny Core Linux but not a regular distro.
> 
> Support for device drivers is somewhat less clear. Losing support for
> 16-bit cards in cardbus sockets is obviously a limiting factor for
> anyone who still has those cards, but there is also a good chance that
> the only reason to keep the cards around is for using them in pre-cardbus
> machines that cannot be upgrade to 32-bit devices.

I think that most users are using CardBus controllers, either in laptops (from Pentium MMX up to Core 2, e.g. DELL Latitude E6400) or as PCI (or even PCIe) adapters for desktop machines.
Users generally treat all the cards as PCMCIA and don't know that there are two kinds of them (16-bit PCMCIA and 32-bit CardBus).

> Completely removing the 16-bit PCMCIA support would however break some
> 20+ year old embedded machines that rely on CompactFlash cards as their
> mass-storage device (extension), this notably includes early PocketPC
> models and the reference implementations for OMAP1, StrongARM1100,
> Alchemy and PA-Semi. All of these are still maintained, though most
> of the PocketPC machines got removed in the 6.3 merge window and the
> PA-Semi Electra board is the only one that was introduced after
> 2003.
> 
> The approach that I take in this series is to split drivers/pcmcia
> into two mutually incompatible parts: the Cardbus support contains
> all the code that is relevant for post-1997 laptops and gets moved
> to drivers/pci/hotplug, while the drivers/pcmcia/ subsystem is
> retained for both the older laptops and the embedded systems but no
> longer works with the yenta socket host driver. The BCM63xx
> PCMCIA/Cardbus host driver appears to be unused and conflicts with
> this series, so it is removed in the process.

This is bad. The drivers remain but could not be used by most machines :(

-- 
Ondrej Zary