mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: [patch 2.6.12-rc5] pcmcia/cs.c and SS_CAP_STATIC_MAP
Date: Sat, 28 May 2005 16:09:26 -0700	[thread overview]
Message-ID: <200505281609.26470.david-b@pacbell.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

I traced a puzzling bug down to the combination of SS_CAP_STATIC_MAP,
finicky hardware, and a bug fixed by the following patch.  The fix
is a one-liner that won't affect any socket driver that's yet merged;
basically, it stops discarding I/O attributes for static mappings.

- Dave


[-- Attachment #2: pcmcia.patch --]
[-- Type: text/x-diff, Size: 1162 bytes --]

The PCMCIA card services layer is never setting the i/o map attributes
when SS_CAP_STATIC_MAP is specified.  Net result, sockets' set_io_map()
calls always see requests with most flags clear, meaning 8 bit access.

For hardware that always autosizes, that won't matter; and all current
STATIC_MAP drivers ignore those attributes.  A new driver (for at91rm9200)
suffers badly from this, since this forces everything into 8 bit mode and
that breaks both (a) cards requiring 16 bit access, and (b) ide-cs; but
of course 8-bit cards work OK (as does accessing card attributes).

So this patch arranges to pass the attributes down, matching the behavior
for non-static mappings (using the first/only I/O window).

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- at91x.orig/drivers/pcmcia/cs.c	2005-05-28 14:20:39.000000000 -0700
+++ at91x/drivers/pcmcia/cs.c	2005-05-28 15:21:06.000000000 -0700
@@ -767,6 +767,7 @@
     }
     if ((s->features & SS_CAP_STATIC_MAP) && s->io_offset) {
 	*base = s->io_offset | (*base & 0x0fff);
+	s->io[0].Attributes = attr;
 	return 0;
     }
     /* Check for an already-allocated window that must conflict with

                 reply	other threads:[~2005-05-28 23:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200505281609.26470.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®