Features Download
From: Michael H. Warfield <mhw <at> WittsEnd.com>
Subject: Re: Re: O2MICRO Smartcardbus reader "Open Port F10000 failed"
Newsgroups: gmane.comp.lib.muscle
Date: Monday 3rd July 2006 15:20:19 UTC (over 11 years ago)
Ah...  Just getting back to this (was at a conference all last week)...

	Hey Andre - see what happens with you post a patch that you know isn't
quite working.  Others help you get it to work and debug it.  :-)

On Wed, 2006-06-21 at 18:38 +0200, Andre Puschmann wrote:
> hi,
> after using dos2unix the patch applied successfully ;-)
> and .. it works for me under 2.6.17, at least pcscd reads from
> /dev/ozscrlx without any errors and recognizes cards .. thank you very
> i haven't tested any other things .. but this will follow ..
> the attached patch against yours adds basic sysfs functionality ..
> you can use for instance this simple udev rule to get a /dev-entry:
> KERNEL=="o2cr*", NAME="ozscrlx%n", GROUP="tty", MODE=660

	We're getting close, real close.

	The above code won't work.  Reason...  That creates "/dev/ozscrlx0" for
the card reader.  That still results in the nefarious "unable to open
port F10000".  Reason is simple enough.  There is a hard coded path to
the /dev/ozscrlx device in src/ozctapi/ctapi.c in the library when
opening a PCMCIA card reader.  It's not using the DEVICE name in the
readers.conf file, so you can't just update that, either.

	Now, I wasn't sure exactly which patches to apply (which ones were
incremental and which were cumulative) so I applied these two patches to
the original sources (after munging the dos2unix thing - which blows
goats, BTW)...




	I then created the file /etc/udev/rules.d/60-o2cr.rules with the
KERNEL= line above.  That didn't quite work and I had to dig through the
library sources when I spotted the absolute path.  So I changed that one
line to this, instead:

KERNEL=="o2cr*", NAME="ozscrlx", GROUP="tty", MODE=660

	(note: dropping the %n in the NAME= stanza)

	That now creates the correct device file and the port can be opened.
What I'm NOT sure about is if this is truly correct in the case where
you have more than one reader.  Since I only have one reader, it works
for me.  I get the impression from reading the code, that this think
will break down and fail with more than one reader.  The library seems
to support more than one reader (up to four) but the driver only accepts
one open per device and I don't see how it's going to mux them,
especially with that hard coded PCMCIA device path.  Looking at the
ctapi code, there are options for non-PCMCIA readers so, maybe, that's
all it's capable of supporting on the PCMCIA bus.  Just one reader.  So
be it, I guess.

	First time I tried talking with a card, it seemed like the driver or
the ctapi library was out of sync or something.  It insisted that a card
was inserted (even when it wasn't) and pscs_scan was returning FF FF FF
FF on the ATR.  :-(  Having rebooted the system a couple of times, it
now seems to be working and it's talking with my Cryptoflex card, but I
have no idea what made it decide to work now.  Time will tell.

	Other problems...  I'm using Fedora Core 5.  The "configure-release"
script is broken trying to update the file /etc/readers.conf.  If it
finds a directory /etc/readers.conf.d then it should just copy it's file
to o2cr.conf in that directory.  It's also not set up for that version
of pcslite installed on this system (1.3.1), so it can't find it's own
readers.conf file AFTER backing up the one one in the /etc directory (it
only seems to have a reader.conf file for 1.2.9 - but there really
shouldn't be any difference).

	The "configure-debug" is really a non-starter.  I wanted a debugging
version of the driver to figure out why they weren't talking and
discovered that the debug version of the driver won't compile (mostly
due to "minor" being undefined in piles of functions).  Looks like it
would take some "minor" tweaks to clean that up (minor is always going
to be 0 for a single card system and, I repeat, I think the multi reader
configuration is going to be majorly hosed anyways).  Looks like I might
now need it now (now that it seems to be working and talking) but,

	To do this correctly, we really should copy those driver sources to a
new directory for 2.6.17 and above, patch them there (fixing the
debugging stuff) and patch the appropriate scripts to build from there
and fix the readers.conf stuff.  I think it needs some looking at from
the standpoint of more than one reader but that's beyond what I'm
willing to tackle at this point.

	The files say they are GPL and was writting by Jeffrey Dai (author
O2Micro) but I can't find an E-Mail addie for him.  Anyone been in
contact with him to get these changes integrated?  We can, under the
GPL, just keep hacking on this sucker but it really should be maintained
and properly integrated.  Be nice if we could provide them with this as

> regards
> andre


> Eric Piel wrote:
> > 06/21/2006 11:17 AM, Andre Puschmann wrote/a écrit:
> >> hi eric,
> >> I'd love to test your patch but somehow the patch doesn't apply
> >> all hunks failed!
> >> did you make this patch against the initial driver from linuxnet.com
> >> against a version already patched??
> >>
> > Yes, I'm aware of this problem, you first have to change the file
> > from Windows to Unix (ie: remove the CR's). For instance you can run
> > this command:
> > recode /CR-LF ozscrlx.c
> > 
> > 
> > 
> >> ps the second version of the patch against 2.6.16 contains your
> >> suggested changes, sorry for not mention that!
> > It's fine now that you've mentioned it :-)
> > 
> > See you,
> > Eric

Michael H. Warfield (AI4NB) | (770) 985-6132 |  [email protected]
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!
CD: 3ms