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: <44FAA61F.9000504@drzeus.cx>
Date:	Sun, 03 Sep 2006 11:53:35 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Greg KH <greg@...ah.com>
CC:	Andrew Morton <akpm@...l.org>, Alex Dubov <oakad@...oo.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash
 card readers

Greg KH wrote:
> On Sat, Sep 02, 2006 at 10:50:14PM +0200, Pierre Ossman wrote:
>   
>>
>> This is a PCI device yes. Which has a number of card readers as
>> separate, hot-pluggable functions. Currently this means it interacts
>> with the block device and MMC subsystems of the kernel. As more drivers
>> pop up, the other card formats will probably get their own subsystems
>> the way MMC has. So there are three issues here:
>>
>>  * Where to put the central module that handles the generic parts of the
>> chip and pulls in the other modules as needed.
>>     
>
> Right now, the drivers/mmc directory has such a driver, the sdhci.c
> file, right?
>
>   

Not quite. sdhci is a vendor-neutral MMC controller driver. What I'm
talking about here is the interface-neutral portion for the Texas
Instruments multi-format card reader.

>>  * If the subfunction modules should be put with the subsystems they
>> connect to or with the main, generic module.
>>     
>
> It all depends on how bit it grows over time.  It is always easy to move
> files around at a later time if you so wish.
>
> For now, is the drivers/mmc/ directory acceptable?  If other card
> formats show up, we can reconsider it at that time.  Is that ok?
>   

Support for MemoryStick isn't that far off in the future, so it would be
preferable to get this right from the start.

Is there no driver in the kernel that already has this design?

Rgds
Pierre


-- 
VGER BF report: U 0.499916
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ