| Message ID | 20230227133457.431729-1-arnd@kernel.org |
|---|---|
| Headers | show |
| Series | pcmcia: separate 16-bit support from cardbus | expand |
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 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 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
+Maxime, On 2/27/2023 5:34 AM, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The bcm63xx pcmcia driver is the only nonstandard cardbus implementation, > everything else is handled by the yenta_socket driver. Upon a closer > look, this seems entirely unused, because: > > - There are two ports for bcm63xx in arch/mips, both of which > support the bcm6358 hardware, but the newer one does not > use this driver at all. > > - The only distro I could find for bcm63xx is OpenWRT, but they > do not enable pcmcia support. However they have 130 patches, > a lot of which are likely required to run anything at all. > > - The device list at https://deviwiki.com/wiki/Broadcom only > lists machines using mini-PCI cards rather than PCMCIA or > Cardbus devices. > > - The cardbus support is entirely made up to work with the > kernel subsystem, but the hardware appears to just be a normal > PCI host that should work fine after removing all the cardbus > code. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> This is probably fine because PCMCIA on BCM63xx was only needed for the very old and early devices like the 6348 which modern kernels are unlikely to be able to run on since they are usually RAM constrained with 16MB or 32MB of DRAM populated. Maxime, do you care if this driver gets removed?
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
On Mon, 2023-02-27 at 13:33 -0800, Florian Fainelli wrote: Hello Florian, > This is probably fine because PCMCIA on BCM63xx was only needed for > the very old and early devices like the 6348 which modern kernels are > unlikely to be able to run on since they are usually RAM constrained > with 16MB or 32MB of DRAM populated. Maxime, do you care if this > driver gets removed? Not at all, thanks for asking.
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%)