linux-kernel - Re: [PATCH] 4/5: Updates to SPI and mmc_spi: mmc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45BA3112.503@drzeus.cx>
Date:	Fri, 26 Jan 2007 17:49:22 +0100
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	Hans-Peter Nilsson <hans-peter.nilsson@...s.com>
CC:	dbrownell@...rs.sourceforge.net, mikael.starvik@...s.com,
	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] 4/5: Updates to SPI and mmc_spi: mmc_spi updated, kernel
 2.6.19

Hans-Peter Nilsson wrote:
> 
> Future improvements:
> A rewrite.  Not only for the new MMC framework (I haven't looked
> at it so I don't know what's involved) but also because this
> code seems a little too, um, experimental to fit my taste.
> Functions go behind each other's back and look at and change
> data; they seem to "fix up" the result of each others work.
> It doesn't help maintenance.
> 

Right, this isn't getting merged anywhere near its current state. It
should be implemented as a host driver and we'll modify the mmc core
where needed to cover the differences when doing spi.

As for my "new framework", it's mostly reorganising the stuff already
there. But any patches will have to be reworked after that change. So
I'd suggest holding off on this for a while.

> Support SDIO and SDHC.  SDIO fails over already when mmc_spi
> sees CMD5 and reports that it's invalid.  This is mostly about
> mapping commands and reply-types, but also support for the SDIO
> interrupt line.  Ok, I guess this can't be properly defined
> before the SDIO and SDHC support at the MMC layer is clear. :)
> 

The response type problem is exactly the kind of problem that should be
solved by moving spi support into the mmc core.

> Better API.  The card-detect API should *at least optionally* be
> like the get_ro function.

I think this is so uncommon and involves so little code that it just
adds complexity to abstract it up to the core. Most hw get interrupts
for insertion/removal.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/