[RFC,0/6] pcmcia: separate 16-bit support from cardbus

  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%)
  

On Mon, Feb 27, 2023, at 20:07, Oliver Hartkopp wrote:
> Hello Arnd,
>
> On 27.02.23 14:34, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>
> (..)
>
>> 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'm using a 2005 Samsung X20 laptop (Pentium M 1.6GHz, Centrino) with 
> PCMCIA (type 2) CAN bus cards:
>
> - EMS PCMCIA
> https://elixir.bootlin.com/linux/latest/source/drivers/net/can/sja1000/ems_pcmcia.c
>
> - PEAK PCCard
> https://elixir.bootlin.com/linux/latest/source/drivers/net/can/sja1000/peak_pcmcia.c
>
> As I still maintain the EMS PCMCIA and had to tweak and test a patch 
> recently (with a 5.16-rc2 kernel):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/can/sja1000/ems_pcmcia.c?id=3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45
>
> I assume these CAN bus PCMCIA interfaces won't work after your patch 
> set, right?

Correct, the patch series in its current form breaks this since
your laptop is cardbus compatible. The options I can see are:

- abandon my series and keep everything unchanged, possibly removing
  some of the pcmcia drivers that Dominik identified as candidates

- decide on a future timeline for when you are comfortable with
  discontinuing this setup and require any CAN users with cardbus
  laptops to move to USB or cardbus CAN adapters, apply the series
  then

- duplicate the yenta_socket driver to have two variants of that,
  require the user to choose between the cardbus and the pcmcia
  variant depending on what card is going to be used.

Can you give more background on who is using the EMS PCMCIA card?
I.e. are there reasons to use this device on modern kernels with
machines that could also support the USB, expresscard or cardbus
variants, or are you likely the only one doing this for the
purpose of maintaining the driver?

      Arnd
  

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.)
  

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 27.02.23 20:53, Arnd Bergmann wrote:
> On Mon, Feb 27, 2023, at 20:07, Oliver Hartkopp wrote:

>> I assume these CAN bus PCMCIA interfaces won't work after your patch
>> set, right?
> 
> Correct, the patch series in its current form breaks this since
> your laptop is cardbus compatible. The options I can see are:
> 
> - abandon my series and keep everything unchanged, possibly removing
>    some of the pcmcia drivers that Dominik identified as candidates
> 
> - decide on a future timeline for when you are comfortable with
>    discontinuing this setup and require any CAN users with cardbus
>    laptops to move to USB or cardbus CAN adapters, apply the series
>    then
> 
> - duplicate the yenta_socket driver to have two variants of that,
>    require the user to choose between the cardbus and the pcmcia
>    variant depending on what card is going to be used.
> 
> Can you give more background on who is using the EMS PCMCIA card?
> I.e. are there reasons to use this device on modern kernels with
> machines that could also support the USB, expresscard or cardbus
> variants, or are you likely the only one doing this for the
> purpose of maintaining the driver?

Haha, good point.

In fact the EMS PCMCIA, the PEAK PCMCIA (PCAN PC Card) and the supported 
Softing PCMCIA cards are nearly 20 year old designs and they are all 
discontinued for some time now. Today you can easily get a high 
performance Classical CAN USB adapter with an excellent OSS firmware for 
~13 EUR.

The only other laptop CAN "Cards" I'm aware of are PCIe "ExpressCard" 
34/54 from PEAK System which use the PCI subsystem.

Maybe you are right and we should simply drop the support for those old 
PCMCIA drivers which will still be supported for the LTS 6.1 lifetime then.

@Marc Kleine-Budde: What do you think about removing these three drivers?

Best regards,
Oliver
  

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 27.02.2023 21:32:40, Oliver Hartkopp wrote:
> On 27.02.23 20:53, Arnd Bergmann wrote:
> > On Mon, Feb 27, 2023, at 20:07, Oliver Hartkopp wrote:
> 
> > > I assume these CAN bus PCMCIA interfaces won't work after your patch
> > > set, right?
> > 
> > Correct, the patch series in its current form breaks this since
> > your laptop is cardbus compatible. The options I can see are:
> > 
> > - abandon my series and keep everything unchanged, possibly removing
> >    some of the pcmcia drivers that Dominik identified as candidates
> > 
> > - decide on a future timeline for when you are comfortable with
> >    discontinuing this setup and require any CAN users with cardbus
> >    laptops to move to USB or cardbus CAN adapters, apply the series
> >    then
> > 
> > - duplicate the yenta_socket driver to have two variants of that,
> >    require the user to choose between the cardbus and the pcmcia
> >    variant depending on what card is going to be used.
> > 
> > Can you give more background on who is using the EMS PCMCIA card?
> > I.e. are there reasons to use this device on modern kernels with
> > machines that could also support the USB, expresscard or cardbus
> > variants, or are you likely the only one doing this for the
> > purpose of maintaining the driver?
> 
> Haha, good point.
> 
> In fact the EMS PCMCIA, the PEAK PCMCIA (PCAN PC Card) and the supported
> Softing PCMCIA cards are nearly 20 year old designs and they are all
> discontinued for some time now. Today you can easily get a high performance
> Classical CAN USB adapter with an excellent OSS firmware for ~13 EUR.
> 
> The only other laptop CAN "Cards" I'm aware of are PCIe "ExpressCard" 34/54
> from PEAK System which use the PCI subsystem.
> 
> Maybe you are right and we should simply drop the support for those old
> PCMCIA drivers which will still be supported for the LTS 6.1 lifetime then.
> 
> @Marc Kleine-Budde: What do you think about removing these three drivers?

I don't have any of these cards, nor any $CUSTOMER who's using it.

Marc
  

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.
  

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 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 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 :(
  

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 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