From: Andreas Mohr <andi@lisas.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Andreas Mohr" <andi@lisas.de>,
"Kristina Martšenko" <kristina.martsenko@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
Subject: Re: [GIT PULL] Staging driver patches for 3.17-rc1
Date: Fri, 15 Aug 2014 04:30:30 +0200 [thread overview]
Message-ID: <20140815023030.GA25537@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <20140805043143.GA31519@kroah.com>
Hi,
late reply due to fatal environment failure, sorry.
On Mon, Aug 04, 2014 at 09:31:43PM -0700, Greg KH wrote:
> On Tue, Aug 05, 2014 at 06:13:25AM +0200, Andreas Mohr wrote:
> > Oh well, yet another driver where it became more difficult rather than
> > easier to make forward progress.
>
> If you are willing to do the work, I will gladly revert the patch and
> look forward to patches to fix the remaining changes.
I've now done further device/driver research
and it looks like this course of action was actually best:
the keucr driver was duplicate/improved functionality of the
ene_ub6250.c driver,
with some extended card type support then relocated into ene_ub6250.c.
The card type relocation work that's still missing is SmartMedia,
but then I do have SM cards and would thus be able to test it.
Thus the duplicated keucr driver could probably stay removed,
with the penalty of having SM support lost at the moment
(since one had to switch drivers anyway
it's uncertain whether that's much of a loss).
The driver also seems to be missing several USB IDs,
as seen from IDs in keucr and Windows .inf file.
Also, firmware files are very old compared to content in current Windows driver
(but it remains to be seen whether new binaries remained compatible
with an old unchanged driver handling, especially given that on Windows
the firmware data is usefully(?) shipped right next to it,
within the same binary).
I'd like to definitely mention here
that this particular device might be well worth improving,
since as opposed to many other USB-based readers
it has a custom programming interface
plus external firmware data,
which could mean that we might be able
to add support for CompactFlash SMART readout
and/or SD card Card Information Struct readout,
on an external USB-based(!) reader.
I will have more time in the near future,
thus I should be able to work on some of these items -
after having completed some other pending driver submissions that is :-P
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
prev parent reply other threads:[~2014-08-15 2:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-04 19:08 Greg KH
2014-08-05 4:13 ` Andreas Mohr
2014-08-05 4:31 ` Greg KH
2014-08-15 2:30 ` Andreas Mohr [this message]
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=20140815023030.GA25537@rhlx01.hs-esslingen.de \
--to=andi@lisas.de \
--cc=akpm@linux-foundation.org \
--cc=devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=kristina.martsenko@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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®