Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master 2009-06-05T14:26:18+00:00 2009-06-05T14:26:18+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-06-05T14:26:18+00:00 urn:sha1:e71d31da062095d8b0b02a26fb5e8879e8d3d0de The source files of firewire-core, firewire-ohci, firewire-sbp2, i.e. "drivers/firewire/fw-*.c" are renamed to "drivers/firewire/core-*.c", "drivers/firewire/ohci.c", "drivers/firewire/sbp2.c". The old fw- prefix was redundant to the directory name. The new core- prefix distinguishes the files according to which driver they belong to. This change comes a little late, but still before further firewire drivers are added as anticipated RSN. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-06-05T14:26:18+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-06-05T14:26:18+00:00 urn:sha1:77c9a5daa9c4d9b37812c9c69c7bcbb3f9399c3c The three header files of firewire-core, i.e. "drivers/firewire/fw-device.h", "drivers/firewire/fw-topology.h", "drivers/firewire/fw-transaction.h", are replaced by "drivers/firewire/core.h", "include/linux/firewire.h". The latter includes everything which a firewire high-level driver (like firewire-sbp2) needs besides linux/firewire-constants.h, while core.h contains the rest which is needed by firewire-core itself and by low- level drivers (card drivers) like firewire-ohci. High-level drivers can now also reside outside of drivers/firewire without having to add drivers/firewire to the header file search path in makefiles. At least the firedtv driver will be such a driver. I also considered to spread the contents of core.h over several files, one for each .c file where the respective implementation resides. But it turned out that most core .c files will end up including most of the core .h files. Also, the combined core.h isn't unreasonably big, and it will lose more of its contents to linux/firewire.h anyway soon when more firewire drivers are added. (IP-over-1394, firedtv, and there are plans for one or two more.) Furthermore, fw-ohci.h is renamed to ohci.h. The name of core.h and ohci.h is chosen with regard to name changes of the .c files in a follow-up change. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-06-05T14:26:17+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-06-04T19:09:38+00:00 urn:sha1:e8ca97021c8eb127bb04aec4e2420e1d66be371d Include required headers which were only indirectly included. Remove unused includes and an unused constant. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-06-05T14:26:17+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-02-15T22:12:34+00:00 urn:sha1:b3b2988841ac6215e137e34e38b71acc915d1f00 That way, the new firedtv driver will be able to use a single ID table in builds against ieee1394 core and/or against firewire core. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-03-24T19:56:40+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2008-12-14T20:47:04+00:00 urn:sha1:53dca51175cc2f66d21aeb1e70146cca65c53dad type function_name(parameters); is nice to look at but was not used consistently. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-01-29T19:19:48+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-01-28T23:11:59+00:00 urn:sha1:c8c4707cf7ca8ff7dcc1653447e48cb3de0bf114 According to https://bugs.launchpad.net/bugs/294391 - 3rd generation iPods need the "fix capacity" workaround after all (apparently they crash after the last sector was accessed), - 2nd generation iPods need the "128 kB maximum request size" workaround. Alas both iPod generations feature the same model ID in the config ROM, hence we can only define a shared quirks list entry for them. Luckily the fix capacity workaround did not show a negative effect in Jarod's tests with 2nd gen. iPod. A side note: Apple computers in target mode (or at least an x86 Mac mini) don't have firmware_version and model_id, hence none of the iPod quirks list entries is active for them. Tested-by: Jarod Wilson <jarod@redhat.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-01-28T19:31:08+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-01-28T00:03:34+00:00 urn:sha1:5e2125677fd72d36396cc537466e07ffcbbd4b2b Reported-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> who also provided a first version of the fix. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-01-28T19:31:07+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-01-24T18:41:46+00:00 urn:sha1:f746072abc12d0e10ecd7847f1846157fde15987 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-01-28T19:31:07+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-01-24T18:41:46+00:00 urn:sha1:a08e100aece16e33a45b82924ad85f4066c4ed1c 1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3). Our previously too large limit doesn't matter though if the controller reports its max_receive correctly. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-01-04T22:50:36+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2008-10-26T10:04:20+00:00 urn:sha1:621f6dd715209d3c3c27841943ae71fc2c75c9f5 What was I thinking when I added sbp2_set_generation()? Its locking did nothing (except for implicitly providing the necessary barrier between node IDs update and generation update). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>