> > Jan 13 18:41:37 localhost kernel: odd IO request: base 0300 align 0010
This is a debugging message, and itself is not a problem; I recently
made some changes to make IO port allocation more flexible and added
this message to catch some unusual situations. The message is not of
general interest and does not indicate anything is wrong.
> Hmm.. This actually looks like a bug that has been there forever. I don't
> know why it hasn't shown itself with the old code, because it looks like
> it was there since day 1.
Actually, it isn't, couldn't, and wasn't. I made the IO allocator
more flexible, which involved using an alignment parameter that had
been ignored in previous versions. To make the change safe, I put in a
test to catch drivers that specified odd values for the alignment
parameter; in that case, the allocator just notes that the request was
odd and reverts to its old behavior.
> if (align && (*base & (align-1)) {
This fix is incorrect. The actual (harmless) oddness is in the
smc91c92_cs driver. There is no bug in alloc_io_space().
The logic for assigning IO ports for PCMCIA devices is tricky. 16-bit
PCMCIA devices are not required to decode all 16 IO address lines.
The CIS is supposed(!!) to say how many IO lines are decoded. This is
converted into a sort of alignment by the IO port allocator, but it
isn't the sort of alignment you're thinking of. The "oddness" check
is to see if the requested base address has upper bits set, when the
alignment indicates the card should not be looking at those bits.
> It is. The old code was a "let's make this work" with not much design, and
> definitely broken for CardBus devices.
I think that's a little unfair. My CardBus support was never intended
to be a permanent solution, and I expected the PCI layer to mature and
take over that functionality. As for the overall design, I did put
quite a lot of thought into it. There may be better ways of doing
various things, but I did not just toss it together.
> > now after 2.3.37, David Hinds refuses to support
> > Kernels above 2.3.37
That's not true. The standalone/userland PCMCIA package requires that
if you are post-2.3.37, you've got to use the in-kernel PCMCIA modules
and kernel CardBus modules, because there wasn't an easy way for me to
accommodate the newer PCI changes. But I've certainly been trying to
make sure everything still cleanly builds against the latest 2.3.*
kernels.
As for supporting the PCMCIA code in the kernel tree, I do not intend
to be unhelpful, but there is a lot of new code in there now, that I
did not write, and I'm not comfortable being primary maintainer for.
I don't ignore 2.3.* bug reports.
> David Hinds agrees with you. He'd rather not touch the PCMCIA subsystem,
> because the old one works, and is held together with years of duct-tape,
> added to make it work.
That's not really true either. I mainly didn't think a rewrite was
wise at this stage in the 2.3/2.4 development cycle, and thought it
would have been better to first get everything working.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:26 EST