[git pull] FireWire fix

[git pull] FireWire fix

[Stefan Richter]

Linus, please pull from the fixes branch at

    git://git.user.in-berlin.de/s5r6/linux1394.git fixes

to receive a hardware quirks flag.  Thanks.

Ming Lei (1):
      firewire: ohci: add no MSI quirk for O2Micro controller

 drivers/firewire/ohci.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


commit f39aa30d7741f40ad964341e9243dbbd7f8ff057
Author: Ming Lei <ming.lei@canonical.com>
Date:   Wed Aug 31 10:45:46 2011 +0800

    firewire: ohci: add no MSI quirk for O2Micro controller
    
    This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 .
    
    An O2Micro PCI Express FireWire controller,
    "FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05)"
    which is a combination device together with an SDHCI controller and some
    sort of storage controller, misses SBP-2 status writes from an attached
    FireWire HDD.  This problem goes away if MSI is disabled for this
    FireWire controller.
    
    The device reportedly does not require QUIRK_CYCLE_TIMER.
    
    Signed-off-by: Ming Lei <ming.lei@canonical.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (amended changelog)
    Cc: <stable@kernel.org>

diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 57cd3a4..fd7170a 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -290,6 +290,9 @@ static const struct {
 	{PCI_VENDOR_ID_NEC, PCI_ANY_ID, PCI_ANY_ID,
 		QUIRK_CYCLE_TIMER},
 
+	{PCI_VENDOR_ID_O2, PCI_ANY_ID, PCI_ANY_ID,
+		QUIRK_NO_MSI},
+
 	{PCI_VENDOR_ID_RICOH, PCI_ANY_ID, PCI_ANY_ID,
 		QUIRK_CYCLE_TIMER},
 
-- 
Stefan Richter
-=====-==-== =--= =---=
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus,

please pull from the tag "firewire-fix" at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git firewire-fix

to receive an IEEE 1394 (FireWire) subsystem fix:
The character device file interface for raw 1394 I/O took uninitialized
kernel stack as substitute for missing ioctl() argument data.  This could
partially show up in subsequent read() output.

Stefan Richter (1):
      firewire: cdev: prevent kernel stack leaking into ioctl arguments

 drivers/firewire/core-cdev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Thanks,
-- 
Stefan Richter
-=====-====- =-== -===-
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus,

please pull from the tag "firewire-fix" at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git firewire-fix

to receive an IEEE 1394 (FireWire) subsystem fix:  The 1394 drivers cannot and
are not supposed to be built on platforms which don't provide the DMA mapping API.
(Regression since v3.16-rc1 with CONFIG_COMPILE_TEST=y on some architectures.)

Geert Uytterhoeven (1):
      firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA

 drivers/firewire/Kconfig | 1 +
 1 file changed, 1 insertion(+)

Thanks,
-- 
Stefan Richter
-=====-====- -=== -===-
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus,

please pull from the tag "firewire-fix" at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git firewire-fix

to get an old bug of the /dev/fw* ioctl ABI fixed.  Thanks.

Stefan Richter (1):
      firewire: cdev: fix user memory corruption (i386 userland on amd64 kernel)

 drivers/firewire/core-cdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
-- 
Stefan Richter
-=====-===-- =-=- -=-=-
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus, please pull from the fixes branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git fixes

for a fix to a regression since v3.0-rc1.  Thanks.

Chris Boot (1):
      firewire: sbp2: fix panic after rmmod with slow targets

 drivers/firewire/sbp2.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)


commit 0278ccd9d53e07c4e699432b2fed9de6c56f506c
Author: Chris Boot <bootc@bootc.net>
Date:   Mon Aug 22 21:38:38 2011 +0100

    firewire: sbp2: fix panic after rmmod with slow targets
    
    If firewire-sbp2 starts a login to a target that doesn't complete ORBs
    in a timely manner (and has to retry the login), and the module is
    removed before the operation times out, you end up with a null-pointer
    dereference and a kernel panic.
    
    [SR:  This happens because sbp2_target_get/put() do not maintain
    module references.  scsi_device_get/put() do, but at occasions like
    Chris describes one, nobody holds a reference to an SBP-2 sdev.]
    
    This patch cancels pending work for each unit in sbp2_remove(), which
    hopefully means there are no extra references around that prevent us
    from unloading. This fixes my crash.
    
    Signed-off-by: Chris Boot <bootc@bootc.net>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

diff --git a/drivers/firewire/sbp2.c b/drivers/firewire/sbp2.c
index 41841a3..17cef86 100644
--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
@@ -1198,6 +1198,10 @@ static int sbp2_remove(struct device *dev)
 {
 	struct fw_unit *unit = fw_unit(dev);
 	struct sbp2_target *tgt = dev_get_drvdata(&unit->device);
+	struct sbp2_logical_unit *lu;
+
+	list_for_each_entry(lu, &tgt->lu_list, link)
+		cancel_delayed_work_sync(&lu->work);
 
 	sbp2_target_put(tgt);
 	return 0;

-- 
Stefan Richter
-=====-==-== =--- ==-==
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus, please pull from the fixes branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git fixes

to receive a quirk handling update to the IEEE 1394 (FireWire) subsystem
for some old first-generation i.LINK enabled camcorders.

This is not a complete solution yet, but a valid improvement on its own
and suitable to be merged this late in the -rc phase.  It is undecided
yet whether the rest of the solution is going to be a more intrusive but
general change to firewire-core transaction layer or a small but less
general adjustment in userspace (libavc1394 and libiec61883).

Stefan Richter (1):
      firewire: core: handle ack_busy when fetching the Config ROM

 drivers/firewire/core-device.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)


commit aaff12039ffd812d0c8bbff50b87b6f1f09bec3e
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sun Aug 7 15:20:18 2011 +0200

    firewire: core: handle ack_busy when fetching the Config ROM
    
    Some older Panasonic made camcorders (Panasonic AG-EZ30 and NV-DX110,
    Grundig Scenos DLC 2000) reject requests with ack_busy_X if a request is
    sent immediately after they sent a response to a prior transaction.
    This causes firewire-core to fail probing of the camcorder with "giving
    up on config rom for node id ...".  Consequently, programs like kino or
    dvgrab are unaware of the presence of a camcorder.
    
    Such transaction failures happen also with the ieee1394 driver stack
    (of the 2.4...2.6 kernel series until 2.6.36 inclusive) but with a lower
    likelihood, such that kino or dvgrab are generally able to use these
    camcorders via the older driver stack.  The cause for firewire-ohci's or
    firewire-core's worse behavior is not yet known.  Gap count optimization
    in firewire-core is not the cause.  Perhaps the slightly higher latency
    of transaction completion in the older stack plays a role.  (ieee1394:
    AR-resp DMA context tasklet -> packet completion ktread -> user process;
    firewire-core: tasklet -> user process.)
    
    This change introduces retries and delays after ack_busy_X into
    firewire-core's Config ROM reader, such that at least firewire-core's
    probing and /dev/fw* creation are successful.  This still leaves the
    problem that userland processes are facing transaction failures.
    gscanbus's built-in retry routines deal with them successfully, but
    neither kino's nor dvgrab's do ever succeed.
    
    But at least DV capture with "dvgrab -noavc -card 0" works now.  Live
    video preview in kino works too, but not actual capture.
    
    One way to prevent Configuration ROM reading failures in application
    programs is to modify libraw1394 to synthesize read responses by means
    of firewire-core's Configuration ROM cache.  This would only leave
    CMP and FCP transaction failures as a potential problem source for
    applications.
    
    Reported-and-tested-by: Thomas Seilund <tps@netmaster.dk>
    Reported-and-tested-by: René Fritz <rene@colorcube.de>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 95a4714..9f661e0 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -455,15 +455,20 @@ static struct device_attribute fw_device_attributes[] = {
 static int read_rom(struct fw_device *device,
 		    int generation, int index, u32 *data)
 {
-	int rcode;
+	u64 offset = (CSR_REGISTER_BASE | CSR_CONFIG_ROM) + index * 4;
+	int i, rcode;
 
 	/* device->node_id, accessed below, must not be older than generation */
 	smp_rmb();
 
-	rcode = fw_run_transaction(device->card, TCODE_READ_QUADLET_REQUEST,
-			device->node_id, generation, device->max_speed,
-			(CSR_REGISTER_BASE | CSR_CONFIG_ROM) + index * 4,
-			data, 4);
+	for (i = 10; i < 100; i += 10) {
+		rcode = fw_run_transaction(device->card,
+				TCODE_READ_QUADLET_REQUEST, device->node_id,
+				generation, device->max_speed, offset, data, 4);
+		if (rcode != RCODE_BUSY)
+			break;
+		msleep(i);
+	}
 	be32_to_cpus(data);
 
 	return rcode;

-- 
Stefan Richter
-=====-==-== =--- =-=-=
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus, please pull from the for-linus branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus

to receive the following firewire driver update.  It is a
straight-forward revert.  Thanks.

Stefan Richter (1):
      firewire: ohci: fix TI TSB82AA2 regression since 2.6.35

 drivers/firewire/ohci.c |   19 +------------------
 drivers/firewire/ohci.h |    8 --------
 2 files changed, 1 insertions(+), 26 deletions(-)


commit aa0170fff3c26bf2b42159af2dd9cf86444c292a
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sun Oct 17 14:09:12 2010 +0200

    firewire: ohci: fix TI TSB82AA2 regression since 2.6.35
    
    Revert commit 54672386ccf36ffa21d1de8e75624af83f9b0eeb
    "firewire: ohci: fix up configuration of TI chips".
    It caused massive slow-down and data corruption with a TSB82AA2 based
    StarTech EC1394B2 ExpressCard and FireWire 800 harddisks.
    
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/657081
    http://thread.gmane.org/gmane.linux.kernel.firewire.user/4013
    
    The fact that some card EEPROMs do not program these enhancements may be
    related to TSB81BA3 phy chip errata, if not to bugs of TSB82AA2 itself.
    We could re-add these configuration steps, but only conditional on a
    whitelist of cards on which these enhancements bring a proven positive
    effect.
    
    Reported-and-tested-by: Eric Shattow <lucent@gmail.com>
    Cc: Clemens Ladisch <clemens@ladisch.de>
    Cc: <stable@kernel.org> 2.6.35
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 1b05896..9dcb17d 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2840,7 +2840,7 @@ static int __devinit pci_probe(struct pci_dev *dev,
 			       const struct pci_device_id *ent)
 {
 	struct fw_ohci *ohci;
-	u32 bus_options, max_receive, link_speed, version, link_enh;
+	u32 bus_options, max_receive, link_speed, version;
 	u64 guid;
 	int i, err, n_ir, n_it;
 	size_t size;
@@ -2894,23 +2894,6 @@ static int __devinit pci_probe(struct pci_dev *dev,
 	if (param_quirks)
 		ohci->quirks = param_quirks;
 
-	/* TI OHCI-Lynx and compatible: set recommended configuration bits. */
-	if (dev->vendor == PCI_VENDOR_ID_TI) {
-		pci_read_config_dword(dev, PCI_CFG_TI_LinkEnh, &link_enh);
-
-		/* adjust latency of ATx FIFO: use 1.7 KB threshold */
-		link_enh &= ~TI_LinkEnh_atx_thresh_mask;
-		link_enh |= TI_LinkEnh_atx_thresh_1_7K;
-
-		/* use priority arbitration for asynchronous responses */
-		link_enh |= TI_LinkEnh_enab_unfair;
-
-		/* required for aPhyEnhanceEnable to work */
-		link_enh |= TI_LinkEnh_enab_accel;
-
-		pci_write_config_dword(dev, PCI_CFG_TI_LinkEnh, link_enh);
-	}
-
 	ar_context_init(&ohci->ar_request_ctx, ohci,
 			OHCI1394_AsReqRcvContextControlSet);
 
diff --git a/drivers/firewire/ohci.h b/drivers/firewire/ohci.h
index 0e6c5a4..ef5e733 100644
--- a/drivers/firewire/ohci.h
+++ b/drivers/firewire/ohci.h
@@ -155,12 +155,4 @@
 
 #define OHCI1394_phy_tcode		0xe
 
-/* TI extensions */
-
-#define PCI_CFG_TI_LinkEnh		0xf4
-#define  TI_LinkEnh_enab_accel		0x00000002
-#define  TI_LinkEnh_enab_unfair		0x00000080
-#define  TI_LinkEnh_atx_thresh_mask	0x00003000
-#define  TI_LinkEnh_atx_thresh_1_7K	0x00001000
-
 #endif /* _FIREWIRE_OHCI_H */



-- 
Stefan Richter
-=====-==-=- =-=- =--=-
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus, please pull from the for-linus branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus

to receive one update which is merely a fix for an old problem from the
POV of the new firewire subsystem, but is a regression fix for those who
migrated from the older ieee1394 to the firewire subsystem.

Stefan Richter (1):
      firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder

 drivers/firewire/core-card.c |   24 +++++++++++++++++++-----
 1 files changed, 19 insertions(+), 5 deletions(-)


Long story because it is a post -rc1 pull request:

This update does *not* affect behavior of firewire-core in presence of
professional video devices, professional audio devices, storage devices,
IP-over-1394 capable nodes.  It *does* change behavior in presence of
consumer video devices, but in a way that mirrors what the ieee1394 core
driver has always been doing and what I suppose 1394 stacks or other
popular OSs do, a way to which 1394-1995 compliant devices are forwards
compatible and which 1394a-2000 and later specs explicitly require to be
implemented.

I suspect that there were more and earlier reports of this
interoperability bug of firewire-core with broken firmwares on Sony
camcorders, but I may have easily mistaken them for mere signs of
degraded old hardware on the electrical level instead of an actual
software/firmware problem.  Due to feature differences between ieee1394
core and firewire-core we never noticed this firmware bug with the older
stack.

commit 10389536742cefbedecb67a5b2906f155cf3a1c3
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Sun May 30 19:43:52 2010 +0200

    firewire: core: check for 1394a compliant IRM, fix inaccessibility of Sony camcorder
    
    Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check
    whether the current IRM complies to 1394a-2000 or later.  If not force a
    compliant node (e.g. itself) to become IRM.  This was implemented in the
    older ieee1394 driver but not yet in firewire-core.
    
    An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM
    but neither 1394a-2000 IRM nor BM was now found to cause an
    interoperability bug:
      - Camcorder becomes root node when plugged in, hence gets IRM role.
      - firewire-core successfully contends for BM role, proceeds to perform
        gap count optimization and resets the bus.
      - Sony camcorder ignores presence of a BM (against the spec, this is
        a firmware bug), performs its idea of gap count optimization and
        resets the bus.
      - Preceding two steps are repeated endlessly, bus never settles,
        regular I/O is practically impossible.
    http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913
    
    This is an interoperability regression from the old to the new drivers.
    Fix it indirectly by adding the 1394a IRM check.  The spec suggests
    three and a half methods to determine 1394a compliance of a remote IRM;
    we choose the method of testing the Config_ROM.Bus_Info.generation
    field.  This is data that firewire-core should have readily available at
    this point, i.e. does not require extra I/O.
    
    Reported-by: Clemens Ladisch <clemens@ladisch.de> (missing 1394a check)
    Reported-by: H. S. <hs.samix@gmail.com> (issue with Sony DCR-TRV25)
    Tested-by: H. S. <hs.samix@gmail.com>
    
    Cc: <stable@kernel.org> # .32.x and newer
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

diff --git a/drivers/firewire/core-card.c b/drivers/firewire/core-card.c
index 9dcb304..371713f 100644
--- a/drivers/firewire/core-card.c
+++ b/drivers/firewire/core-card.c
@@ -231,7 +231,7 @@ void fw_schedule_bm_work(struct fw_card *card, unsigned long delay)
 static void fw_card_bm_work(struct work_struct *work)
 {
 	struct fw_card *card = container_of(work, struct fw_card, work.work);
-	struct fw_device *root_device;
+	struct fw_device *root_device, *irm_device;
 	struct fw_node *root_node;
 	unsigned long flags;
 	int root_id, new_root_id, irm_id, local_id;
@@ -239,6 +239,7 @@ static void fw_card_bm_work(struct work_struct *work)
 	bool do_reset = false;
 	bool root_device_is_running;
 	bool root_device_is_cmc;
+	bool irm_is_1394_1995_only;
 
 	spin_lock_irqsave(&card->lock, flags);
 
@@ -248,12 +249,18 @@ static void fw_card_bm_work(struct work_struct *work)
 	}
 
 	generation = card->generation;
+
 	root_node = card->root_node;
 	fw_node_get(root_node);
 	root_device = root_node->data;
 	root_device_is_running = root_device &&
 			atomic_read(&root_device->state) == FW_DEVICE_RUNNING;
 	root_device_is_cmc = root_device && root_device->cmc;
+
+	irm_device = card->irm_node->data;
+	irm_is_1394_1995_only = irm_device && irm_device->config_rom &&
+			(irm_device->config_rom[2] & 0x000000f0) == 0;
+
 	root_id  = root_node->node_id;
 	irm_id   = card->irm_node->node_id;
 	local_id = card->local_node->node_id;
@@ -276,8 +283,15 @@ static void fw_card_bm_work(struct work_struct *work)
 
 		if (!card->irm_node->link_on) {
 			new_root_id = local_id;
-			fw_notify("IRM has link off, making local node (%02x) root.\n",
-				  new_root_id);
+			fw_notify("%s, making local node (%02x) root.\n",
+				  "IRM has link off", new_root_id);
+			goto pick_me;
+		}
+
+		if (irm_is_1394_1995_only) {
+			new_root_id = local_id;
+			fw_notify("%s, making local node (%02x) root.\n",
+				  "IRM is not 1394a compliant", new_root_id);
 			goto pick_me;
 		}
 
@@ -316,8 +330,8 @@ static void fw_card_bm_work(struct work_struct *work)
 			 * root, and thus, IRM.
 			 */
 			new_root_id = local_id;
-			fw_notify("BM lock failed, making local node (%02x) root.\n",
-				  new_root_id);
+			fw_notify("%s, making local node (%02x) root.\n",
+				  "BM lock failed", new_root_id);
 			goto pick_me;
 		}
 	} else if (card->bm_generation != generation) {


Thanks,
-- 
Stefan Richter
-=====-==-=- -==- -=---
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

Linus, please pull from the for-linus branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus

to receive a FireWire subsystem fix.

Jay Fenlason (1):
      firewire: ohci: handle receive packets with a data length of zero

 drivers/firewire/ohci.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

Thanks.


commit 8c0c0cc2d9f4c523fde04bdfe41e4380dec8ee54
Author: Jay Fenlason <fenlason@redhat.com>
Date:   Fri Dec 11 14:23:58 2009 -0500

    firewire: ohci: handle receive packets with a data length of zero
    
    Queueing to receive an ISO packet with a payload length of zero
    silently does nothing in dualbuffer mode, and crashes the kernel in
    packet-per-buffer mode.  Return an error in dualbuffer mode, because
    the DMA controller won't let us do what we want, and work correctly in
    packet-per-buffer mode.
    
    Signed-off-by: Jay Fenlason <fenlason@redhat.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
    Cc: stable@kernel.org

diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index a714775..553c74e 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2189,6 +2189,13 @@ static int ohci_queue_iso_receive_dualbuffer(struct fw_iso_context *base,
 	page     = payload >> PAGE_SHIFT;
 	offset   = payload & ~PAGE_MASK;
 	rest     = p->payload_length;
+	/*
+	 * The controllers I've tested have not worked correctly when
+	 * second_req_count is zero.  Rather than do something we know won't
+	 * work, return an error
+	 */
+	if (rest == 0)
+		return -EINVAL;
 
 	/* FIXME: make packet-per-buffer/dual-buffer a context option */
 	while (rest > 0) {
@@ -2242,7 +2249,7 @@ static int ohci_queue_iso_receive_packet_per_buffer(struct fw_iso_context *base,
 					unsigned long payload)
 {
 	struct iso_context *ctx = container_of(base, struct iso_context, base);
-	struct descriptor *d = NULL, *pd = NULL;
+	struct descriptor *d, *pd;
 	struct fw_iso_packet *p = packet;
 	dma_addr_t d_bus, page_bus;
 	u32 z, header_z, rest;
@@ -2280,8 +2287,9 @@ static int ohci_queue_iso_receive_packet_per_buffer(struct fw_iso_context *base,
 		d->data_address = cpu_to_le32(d_bus + (z * sizeof(*d)));
 
 		rest = payload_per_buffer;
+		pd = d;
 		for (j = 1; j < z; j++) {
-			pd = d + j;
+			pd++;
 			pd->control = cpu_to_le16(DESCRIPTOR_STATUS |
 						  DESCRIPTOR_INPUT_MORE);
 
-- 
Stefan Richter
-=====-==--= ==-- -=-==
http://arcgraph.de/sr/

[git pull] FireWire fix

[Stefan Richter]

On  9 Jan, Greg KH wrote:
> On Fri, Jan 09, 2009 at 09:17:18PM +0000, Alan Cox wrote:
>> On Fri, 9 Jan 2009 20:49:37 +0100 (CET)
>> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> 
>> > Due to commit 2831fe6f9cc4e16c103504ee09a47a084297c0f3, "driver core:
>> > create a private portion of struct device", device_initialize() can no
>> > longer be called from atomic contexts.
>> 
>> I don't see why this is neccessary or appropriate - the original commit
>> needs to be pulled and the private area allocation rethought.
> 
> Ugh, I think you're right.  I'll revert this (and all of the patches in
> the series that were needed to get this working properly), and redo the
> patch set, first making device_initialize() able to fail, and auditing
> all callers to make sure it's not being called in atomic context.
> 
> At first glance, I think it's only firewire that is doing this in atomic
> context, so Stefan, I wouldn't mind seeing your patch go in as-is just
> to make things simpler overall.
> 
> I'll go make up the patchset and send them to Linus...

Linus,

please pull from the for-linus branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus

to receive the following change --- as a hotfix for now, and to expand
Greg's options when he sorts device_initialize() out later.

Stefan Richter (1):
      firewire: core: fix sleep in atomic context due to driver core change

 drivers/firewire/fw-card.c   |   13 +++++++------
 drivers/firewire/fw-device.c |   23 +++++++++++++----------
 2 files changed, 20 insertions(+), 16 deletions(-)


commit 6230582320b721e6cf2581d048cb688dca97f504
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Fri Jan 9 20:49:37 2009 +0100

    firewire: core: fix sleep in atomic context due to driver core change
    
    Due to commit 2831fe6f9cc4e16c103504ee09a47a084297c0f3, "driver core:
    create a private portion of struct device", device_initialize() can no
    longer be called from atomic contexts.
    
    We now defer it until after config ROM probing.  This requires changes
    to the bus manager code because this may use a device before it was
    probed.
    
    Reported-by: Jay Fenlason <fenlason@redhat.com>
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

diff --git a/drivers/firewire/fw-card.c b/drivers/firewire/fw-card.c
index 799f944..6bd91a1 100644
--- a/drivers/firewire/fw-card.c
+++ b/drivers/firewire/fw-card.c
@@ -209,6 +209,8 @@ fw_card_bm_work(struct work_struct *work)
 	unsigned long flags;
 	int root_id, new_root_id, irm_id, gap_count, generation, grace, rcode;
 	bool do_reset = false;
+	bool root_device_is_running;
+	bool root_device_is_cmc;
 	__be32 lock_data[2];
 
 	spin_lock_irqsave(&card->lock, flags);
@@ -224,8 +226,9 @@ fw_card_bm_work(struct work_struct *work)
 
 	generation = card->generation;
 	root_device = root_node->data;
-	if (root_device)
-		fw_device_get(root_device);
+	root_device_is_running = root_device &&
+			atomic_read(&root_device->state) == FW_DEVICE_RUNNING;
+	root_device_is_cmc = root_device && root_device->cmc;
 	root_id = root_node->node_id;
 	grace = time_after(jiffies, card->reset_jiffies + DIV_ROUND_UP(HZ, 10));
 
@@ -308,14 +311,14 @@ fw_card_bm_work(struct work_struct *work)
 		 * config rom.  In either case, pick another root.
 		 */
 		new_root_id = local_node->node_id;
-	} else if (atomic_read(&root_device->state) != FW_DEVICE_RUNNING) {
+	} else if (!root_device_is_running) {
 		/*
 		 * If we haven't probed this device yet, bail out now
 		 * and let's try again once that's done.
 		 */
 		spin_unlock_irqrestore(&card->lock, flags);
 		goto out;
-	} else if (root_device->cmc) {
+	} else if (root_device_is_cmc) {
 		/*
 		 * FIXME: I suppose we should set the cmstr bit in the
 		 * STATE_CLEAR register of this node, as described in
@@ -362,8 +365,6 @@ fw_card_bm_work(struct work_struct *work)
 		fw_core_initiate_bus_reset(card, 1);
 	}
  out:
-	if (root_device)
-		fw_device_put(root_device);
 	fw_node_put(root_node);
 	fw_node_put(local_node);
  out_put_card:
diff --git a/drivers/firewire/fw-device.c b/drivers/firewire/fw-device.c
index c173be3..2af5a8d 100644
--- a/drivers/firewire/fw-device.c
+++ b/drivers/firewire/fw-device.c
@@ -159,7 +159,8 @@ static void fw_device_release(struct device *dev)
 
 	/*
 	 * Take the card lock so we don't set this to NULL while a
-	 * FW_NODE_UPDATED callback is being handled.
+	 * FW_NODE_UPDATED callback is being handled or while the
+	 * bus manager work looks at this node.
 	 */
 	spin_lock_irqsave(&card->lock, flags);
 	device->node->data = NULL;
@@ -695,12 +696,13 @@ static void fw_device_init(struct work_struct *work)
 		return;
 	}
 
-	err = -ENOMEM;
+	device_initialize(&device->device);
 
 	fw_device_get(device);
 	down_write(&fw_device_rwsem);
-	if (idr_pre_get(&fw_device_idr, GFP_KERNEL))
-		err = idr_get_new(&fw_device_idr, device, &minor);
+	err = idr_pre_get(&fw_device_idr, GFP_KERNEL) ?
+	      idr_get_new(&fw_device_idr, device, &minor) :
+	      -ENOMEM;
 	up_write(&fw_device_rwsem);
 
 	if (err < 0)
@@ -911,13 +913,14 @@ void fw_node_event(struct fw_card *card, struct fw_node *node, int event)
 
 		/*
 		 * Do minimal intialization of the device here, the
-		 * rest will happen in fw_device_init().  We need the
-		 * card and node so we can read the config rom and we
-		 * need to do device_initialize() now so
-		 * device_for_each_child() in FW_NODE_UPDATED is
-		 * doesn't freak out.
+		 * rest will happen in fw_device_init().
+		 *
+		 * Attention:  A lot of things, even fw_device_get(),
+		 * cannot be done before fw_device_init() finished!
+		 * You can basically just check device->state and
+		 * schedule work until then, but only while holding
+		 * card->lock.
 		 */
-		device_initialize(&device->device);
 		atomic_set(&device->state, FW_DEVICE_INITIALIZING);
 		device->card = fw_card_get(card);
 		device->node = fw_node_get(node);



Thanks,
-- 
Stefan Richter
-=====-==--= ---= -=--=
http://arcgraph.de/sr/

[GIT PULL] FireWire fix

[Stefan Richter]

Linus, please pull from the for-linus branch at

    git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus

to receive a fix of the laptop-refuses-to-suspend kind. Or simply apply
the patch from this mail.


There is still an old underlying oddness though which I ask the PPC
folks to investigate and possibly fix post 2.6.23:  On iBook G3 and
older PowerBooks, the onboard FireWire controller's pci_dev
current_state remains PCI_UNKNOWN long after initialization. Sounds like
a bug in platform code to me.


Stat, log, diff:

 drivers/firewire/fw-ohci.c |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

commit 5511142870046a7bed947d51ec9b320856ee120a
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date:   Thu Sep 6 09:50:30 2007 +0200

    firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
    
    Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
    http://lkml.org/lkml/2007/8/25/155.  The issue is that the FireWire
    controller's pci_dev.current_state of iBook G3 and presumably older
    PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
    driver's .suspend method is called.
    
    Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
    do not fail .suspend anymore if pci_set_power_state failed.
    
    Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

diff --git a/drivers/firewire/fw-ohci.c b/drivers/firewire/fw-ohci.c
index 7e427b4..e14c1ca 100644
--- a/drivers/firewire/fw-ohci.c
+++ b/drivers/firewire/fw-ohci.c
@@ -1945,10 +1945,8 @@ static int pci_suspend(struct pci_dev *pdev, pm_message_t state)
 		return err;
 	}
 	err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
-	if (err) {
-		fw_error("pci_set_power_state failed\n");
-		return err;
-	}
+	if (err)
+		fw_error("pci_set_power_state failed with %d\n", err);
 
 	return 0;
 }

-- 
Stefan Richter
-=====-=-=== =--= --===
http://arcgraph.de/sr/