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: <4A413F8F.6030500@bluewatersys.com>
Date:	Wed, 24 Jun 2009 08:48:15 +1200
From:	Ryan Mallon <ryan@...ewatersys.com>
To:	Linus Walleij <linus.ml.walleij@...il.com>
CC:	David Woodhouse <dwmw2@...radead.org>,
	linux-mtd@...ts.infradead.org,
	spi-devel-general@...ts.sourceforge.net, mike@...roidmicros.com,
	linux kernel <linux-kernel@...r.kernel.org>,
	dedekind@...radead.org
Subject: Re: [PATCH] SST25L (non JEDEC) SPI Flash driver

Linus Walleij wrote:
> 2009/6/22 Ryan Mallon <ryan@...ewatersys.com>:
> 
>> Out of curiosity: I'm not too clear on what makes a particular chip
>> hot-pluggable. I think technically the sst25l chip could be put onto a
>> hot-pluggable board or power domain. Can't most devices be made
>> hot-pluggable? Is the general rule to make devices non hot-pluggable if
>> most/all boards in the mainline do not allow it to be hot-plugged?
> 
> I haven't seen any rule about it, but nominally the drivers support the
> configurations found in the kernel tree, so if some board physically
> existing and soon-to-run linux hotplugs chips like this, then have it
> __dev{init|exit} else __{init|exit} IMHO.
> 
> Of course you can design for all plausible use cases but it will pile up
> indefinitely. Personally I try to not design software for a hardware until it
> exists, and I like the IETF catch-phrase "rough consensus and running
> code" and this sort of fits that :-)

Okay, thanks. Thats basically the conclusion we came to as well: if
someone else wants to hotplug this chip in the future they can post a
patch for it.

BTW, most of my other patches go via the ARM list, which uses the patch
system. Whats the procedure for most other lists, do patches just get
collected by the subsection maintainer when they are okay?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

       Ryan Mallon                              Unit 5, Amuri Park
       Phone: +64 3 3779127                     404 Barbadoes St
       Fax:   +64 3 3779135                     PO Box 13 889
       Email: ryan@...ewatersys.com             Christchurch, 8013
       Web:   http://www.bluewatersys.com       New Zealand
       Freecall Australia  1800 148 751         USA 1800 261 2934
--
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