Dominik Brodowski linux at
Fri Apr 11 23:03:22 BST 2003


On Fri, Apr 11, 2003 at 12:52:29PM -0400, Pavel Roskin wrote:
> On Fri, 11 Apr 2003, Dominik Brodowski wrote:
> > > ... and it was the first message to the list.
> >
> > Really? IIRC there was a test message to the list by dwmw before I
> > subscribed, and I sent one to the list, too :)
> Look for yourself:

Strangely, this archive is empty. Even though I just verified I sent (at
least) two messages to the list... and even got a response by dwmw on me
sending a message to that list :) strange...

> Maybe you mean a mailing list on SourceForge?  There was a project there.
> The CVS repository had something like 4 files.  I cannot find that project
> anymore.
> By the way, we really need CVS for the project.  Maybe it should be
> another project on Sourceforge?

Hm, you sure we really need CVS? Small patches / patchsets are easily kept
without CVS; I don't want to accumulate large blacklogs of patches (what's
in the queue right now is more than enough...); and for pushing changes to
Linus BK seems to be a better choice. Or do you/dwmw have objections to BK? I'm
currently testing BK for personal use... And what's your idea about this, Russell?

Oh and maybe it'd be possible to use for all our
(internal) merging. 

Also, there's already a CVS repository at for the
"complete-rework" of PCMCIA. If we continue to improve PCMCIA by small
upgrades this project which never really got off the ground might become

> > > We could also "cripple" yenta_socket and disable remapping of resources.
> > > That would be useful for fixing client drivers.
> >
> > /me has (almost) no idea about PCMCIA resource handling yet, that's
> > Russell's call to make :)
> As I understand it, pcmcia_core requests the socket driver to provide a
> window (memory or I/O) is a certain region to the given resource.  The
> socket driver is not supposed to own that resource (unless it indicates
> that it has a static map, but most "normal" sockets don't).  Then
> pcmcia_core reserves the resource and gives it to the client driver.
> Although it's possible to request the existing mapping from the socket
> driver, this code is not used.  pcmcia_core essentially assumes that its
> requests are always satisfied.
> For example, plx9052 can provide a 0x40 bytes long I/O window in the
> region is already owns as a PCI resource.  In my case, it's
> 0xc000-0xc003f.  pcnet_cs wants to get an I/O resource at 0x300.
> pcmcia_core notices that plx9052 has a fixed I/O window (thanks for that,
> David Hinds' pcmcia-cs doesn't support io_offset at all) in
> alloc_io_space() and guess what it does?
> It removes bits 12 and above from the address by ANDing it with 0x0fff,
> wrongly assuming that every driver can remap its I/O space withing 4k
> after the base address.  Then it "extends" (!!!) the window and gives the
> driver a window at 0xc300.  Not only is this region not allocated by the
> socket driver, but the socket driver refuses to relocate the resource
> there.  It's outrageous!

Well, I'll let you and Russell handle this -- he was away the last week, so
he has quite some email to catch up with; so it might take a few days until
you/we get a response.
> > > Thank you for this information.  I think I'll start with making the
> > > plx9052 driver work with pcnet_cs and ide-cs.  I also want to remove
> > > timers from the drivers I can test.
> >
> > That's great! Thanks!
> Can I have CVS access for those drivers?  I also would like to work on the
> orinoco driver, because I know it very well, and because I have already
> done some work on improving it's PCMCIA interface.  I'm not going to do
> any architecture changes without your approval.

/me fears indeed becoming the PCMCIA maintainer for 2.5... I have no idea if
anybody else is considered being maintainer of orinoco, pcnet_cs and/or
ide-cs. There are names mentioned in the pcmcia-cs package; but I think they
are more or less unmaintained in their in-kernel incarnation. But maybe we
can find this out looking at the changelog of Linus' tree?


More information about the linux-pcmcia mailing list