linux at brodo.de
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
> 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 linux-pcmcia.bkbits.net for all our
Also, there's already a CVS repository at infradead.org 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