gmane.linux.kernel.firewire.devel

Changes to the FireWire kernel drivers in Linux 3.4

Stefan Richter — 2012-05-24T20:44:47

Hi all,

Linux kernel 3.4 has been released last Sunday.  These are the IEEE 1394
related changes:

<linux/firewire-cdev.h> API:
  - Added FW_CDEV_IOC_FLUSH_ISO ioctl which lets an application get any
    currently completed isochronous packets reported.  A corresponding
    libraw1394 update to use this ioctl in raw1394_iso_recv_flush() has
    been committed to libraw1394.git too and will show up in the next
    libraw1394 release.

firewire-core, -net, -ohci, -sbp2:
  - All messages to the kernel log are now consistently prefixed by driver
    name and device name or number.

firewire-ohci:
  - Fix premature completion of multichannel isochronous reception DMA.
    Also fixed in kernel 3.3.1, 3.2.14, 3.0.27.
  - Fix missing completion notification in isochronous I/O in case of big
    intervals between interrupt packets or with big packet headers.

firewire-sbp2:
  - If the target's unit directory contains a Unit_Unique_ID entry, use it
    instead of the node unique ID as the target's GUID in the ieee1394_id
    sysfs attribute and consequently in udev's /dev/disk/by-id symbolic
    links.
  - Do not try to log into targets on the local node. I/O to such targets
    is not yet implemented, and local targets are probably meant to be
    accessed by remote initiators anyway.
  - Fix handling of SCSI sense data (deferred errors, Valid, Filemark,
    EOM, ILI).

[git pull] FireWire updates post v3.4

Stefan Richter — 2012-05-24T19:14:55

Linus,

please pull from the tag "firewire-updates" at

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

to receive the following IEEE 1394 (FireWire) subsystem updates:

  - Fix mismatch between DMA mapping direction (was wrong) and DMA synchronization
    direction (was correct) of isochronous reception buffers of userspace drivers
    if vma-mapped for R/W access.  For example, libdc1394 was affected.

  - more consistent retry stategy in device discovery/ rediscovery, and improved
    failure diagnostics

  - various small cleanups, e.g. use SCSI layer's DMA mapping API in firewire-sbp2

The last few commits happened rather late for this pull request but I feel comfortable
with them.  ALSA firewire-lib changes were written by Clemens, hence are implicitly ACKed.

Axel Lin (1):
      firewire: use module_pci_driver

Clemens Ladisch (10):
      firewire: core: wait for inaccessible devices after bus reset
      firewire: core: improve reread_config_rom() interface
      firewire: move rcode_string() to core
      firewire: core: log error in case of failed bus manager lock
      firewire: core: log config rom reading errors
      firewire: core: fw_device_refresh(): clean up error handling
      firewire: sbp2: give correct DMA device to scsi framework
      firewire: sbp2: use scsi_dma_(un)map
      firewire: sbp2: remove superfluous blk_queue_max_segment_size() call
      firewire: sbp2: document the absence of alignment requirements

Stefan Richter (4):
      firewire: core: fix DMA mapping direction
      firewire: ohci: correct signedness of a local variable
      firewire: ohci: omit spinlock IRQ flags where possible
      Merge tag 'v3.4' with SCSI updates, needed for subsequent firewire-sbp2 changes

 drivers/firewire/core-card.c        |    4 +-
 drivers/firewire/core-cdev.c        |   51 ++++++++++++---
 drivers/firewire/core-device.c      |  116 +++++++++++++++++------------------
 drivers/firewire/core-iso.c         |   80 +++++++++++++++---------
 drivers/firewire/core-transaction.c |   26 ++++++++
 drivers/firewire/core.h             |    7 ++-
 drivers/firewire/nosy.c             |   20 ++----
 drivers/firewire/ohci.c             |   42 +++++--------
 drivers/firewire/sbp2.c             |   28 ++++-----
 include/linux/firewire.h            |    2 +
 sound/firewire/cmp.c                |    2 +-
 sound/firewire/lib.c                |   28 +--------
 sound/firewire/lib.h                |    1 -
 13 files changed, 218 insertions(+), 189 deletions(-)

Thanks,

[PATCH] firewire: ohci: lazy bus time initialization

Clemens Ladisch — 2012-05-24T17:29:19

The Bus_Time CSR is virtually never used, so we can avoid burning CPU in
interrupt context for 1 or 3 IsochronousCycleTimer accesses every minute
by not tracking the bus time until the CSR is actually accessed for the
first time.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 drivers/firewire/ohci.c |   18 ++++++++++++------
 1 files changed, 12 insertions(+), 6 deletions(-)

--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
< at >< at > -191,6 +191,7 < at >< at > struct fw_ohci {
 unsigned quirks;
 unsigned int pri_req_max;
 u32 bus_time;
+bool bus_time_running;
 bool is_root;
 bool csr_state_setclear_abdicate;
 int n_ir;
< at >< at > -1741,6 +1742,13 < at >< at > static u32 update_bus_time(struct fw_ohci *ohci)
 {
 u32 cycle_time_seconds = get_cycle_time(ohci) >> 25;

+if (unlikely(!ohci->bus_time_running)) {
+reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_cycle64Seconds);
+ohci->bus_time = (lower_32_bits(get_seconds()) & ~0x7f) |
+                 (cycle_time_seconds & 0x40);
+ohci->bus_time_running = true;
+}
+
 if ((ohci->bus_time & 0x40) != (cycle_time_seconds & 0x40))
 ohci->bus_time += 0x40;

< at >< at > -2261,7 +2269,7 < at >< at > static int ohci_enable(struct fw_card *card,
 {
 struct fw_ohci *ohci = fw_ohci(card);
 struct pci_dev *dev = to_pci_dev(card->device);
-u32 lps, seconds, version, irqs;
+u32 lps, version, irqs;
 int i, ret;

 if (software_reset(ohci)) {
< at >< at > -2320,9 +2328,7 < at >< at > static int ohci_enable(struct fw_card *card,
   (OHCI1394_MAX_PHYS_RESP_RETRIES << 8) |
   (200 << 16));

-seconds = lower_32_bits(get_seconds());
-reg_write(ohci, OHCI1394_IsochronousCycleTimer, seconds << 25);
-ohci->bus_time = seconds & ~0x3f;
+ohci->bus_time_running = false;

 version = reg_read(ohci, OHCI1394_Version) & 0x00ff00ff;
 if (version >= OHCI_VERSION_1_1) {
< at >< at > -2420,7 +2426,6 < at >< at > static int ohci_enable(struct fw_card *card,
 OHCI1394_postedWriteErr |
 OHCI1394_selfIDComplete |
 OHCI1394_regAccessFail |
-OHCI1394_cycle64Seconds |
 OHCI1394_cycleInconsistent |
 OHCI1394_unrecoverableError |
 OHCI1394_cycleTooLong |
< at >< at > -2709,7 +2714,8 < at >< at > static void ohci_write_csr(struct fw_card *card, int csr_offset, u32 value)

 case CSR_BUS_TIME:
 spin_lock_irqsave(&ohci->lock, flags);
-ohci->bus_time = (ohci->bus_time & 0x7f) | (value & ~0x7f);
+ohci->bus_time = (update_bus_time(ohci) & 0x40) |
+                 (value & ~0x7f);
 spin_unlock_irqrestore(&ohci->lock, flags);
 break;


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH 2/2] firewire: core: allocate the low memory region

Clemens Ladisch — 2012-05-24T17:28:58

Prevent userspace applications from allocating low memory address
ranges.  Otherwise, if some application happens to allocate such
a range and intends for a remote node to access it, and if that node
also implements SBP-2 (which will become more likely with the upcoming
SBP-2 target support), these accesses would be routed by the physical
DMA unit to some wrong memory address.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 drivers/firewire/core-transaction.c |   23 +++++++++++++++++++++--
 1 files changed, 21 insertions(+), 2 deletions(-)

--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
< at >< at > -525,9 +525,10 < at >< at > const struct fw_address_region fw_high_memory_region =
 { .start = 0x000100000000ULL, .end = 0xffffe0000000ULL,  };
 EXPORT_SYMBOL(fw_high_memory_region);

-#if 0
-const struct fw_address_region fw_low_memory_region =
+static const struct fw_address_region low_memory_region =
 { .start = 0x000000000000ULL, .end = 0x000100000000ULL,  };
+
+#if 0
 const struct fw_address_region fw_private_region =
 { .start = 0xffffe0000000ULL, .end = 0xfffff0000000ULL,  };
 const struct fw_address_region fw_csr_region =
< at >< at > -1189,6 +1190,23 < at >< at > static struct fw_address_handler registers = {
 .address_callback= handle_registers,
 };

+static void handle_low_memory(struct fw_card *card, struct fw_request *request,
+int tcode, int destination, int source, int generation,
+unsigned long long offset, void *payload, size_t length,
+void *callback_data)
+{
+/*
+ * This catches requests not handled by the physical DMA unit,
+ * i.e., wrong transaction types or unauthorized source nodes.
+ */
+fw_send_response(card, request, RCODE_TYPE_ERROR);
+}
+
+static struct fw_address_handler low_memory = {
+.length= 0x000100000000ULL,
+.address_callback= handle_low_memory,
+};
+
 MODULE_AUTHOR("Kristian Hoegsberg <krh< at >bitplanet.net>");
 MODULE_DESCRIPTION("Core IEEE1394 transaction logic");
 MODULE_LICENSE("GPL");
< at >< at > -1279,6 +1297,7 < at >< at > static int __init fw_core_init(void)
 set_text_desc(&model_id_descriptor, model);
 fw_core_add_address_handler(&topology_map, &topology_map_region);
 fw_core_add_address_handler(&registers, &registers_region);
+fw_core_add_address_handler(&low_memory, &low_memory_region);
 fw_core_add_descriptor(&vendor_id_descriptor);
 fw_core_add_descriptor(&model_id_descriptor);


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH 1/2] firewire: core: make address handler length 64 bits

Clemens Ladisch — 2012-05-24T17:28:17

The type of the length field of the fw_address_handler structure was
size_t, which restricted it to 32 bits on 32-bit architectures.

While making it u32 would match the userspace API, all calculations on
this field use 64 bits anyway, and the ability to use 4 GB or larger
address ranges is useful in the kernel.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 include/linux/firewire.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

--- a/include/linux/firewire.h
+++ b/include/linux/firewire.h
< at >< at > -307,7 +307,7 < at >< at > struct fw_transaction {

 struct fw_address_handler {
 u64 offset;
-size_t length;
+u64 length;
 fw_address_callback_t address_callback;
 void *callback_data;
 struct list_head link;

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

cycle64Seconds IRQ (was Re: firewire_ohci : Register access failure- please notify linux1394-devel< at >lists.sf.net)

Stefan Richter — 2012-05-24T06:36:41

Even though his did not help with the O2Micro controller problem, it seems
a generally useful change to me.  Why burn CPU in interrupt context for
1 or 3 IsochronousCycleTimer accesses every minute if it just needed for
the Bus_Time CSR which is virtually never used.  Do you agree and could
resend it as proper patch?

Re: [GIT PULL] sbp-target merge for v3.5-rc1

Stefan Richter — 2012-05-23T05:01:47

[...]
[...]
[...]

As noted in the changelogs:
Acked-by: Stefan Richter <stefanr< at >s5r6.in-berlin.de>

Re: [Bug 43244] New: firewire_ohci prevents boot

Stefan Richter — 2012-05-21T20:08:30

If there is anything more than that on the text console when the PC locks
up and you have a digital camera at your disposal, just take a photograph,
attach it to bugzilla, and post the link.

If there is nothing interesting to photograph, then you could try
netconsole.  You need a second PC on which you configure syslogd to
receive log messages from the test PC.  On the test PC, you need to have
netconsole loaded before the lockup and need to specify the target.

Here is what works for me:

On the logging PC at 192.168.0.37:
----------------------------------
$ tail -3 /etc/syslog-ng/syslog-ng.conf 
# netconsole:
source net { udp(ip("192.168.0.37") port(6666)); };
log { source(net); destination(messages); };

On the test PC:
---------------
# alias netconsole
alias netconsole='modprobe netconsole netconsole="< at >/,< at >192.168.0.37/" && dmesg -n 7'

Since you crash at boot, I guess it's easiest to link netconsole
statically into the kernel and of course specify the parameter in the
bootloader's kernel command line.

Re: [PATCH] firewire-sbp2: Initialise sbp2_orb->rcode formanagement ORBs

Stefan Richter — 2012-05-19T10:29:49

[...]
[...]

Chris, I obviously haven't done anything about this potentially too short
retry period yet; it is still on my list.

Perhaps we should not count the number of retries but watch the time that
retries take.  I.e. accumulate the time that each try takes; break out of
the retry loop after a maximum time; but reset the accumulated time at a
bus reset as a precaution for buses with many nodes coming online at
different times.

Re: [PATCH 4/4] firewire: sbp2: remove overzealous alignmentconstraints

Stefan Richter — 2012-05-18T19:08:55

On May 18 Clemens Ladisch wrote at linux1394-devel:

SBP-2 clause 3.1.2.24 requires that system memory accepts quadlet r/w
access.  Memory which is not aligned at quadlet boundaries is not
accessible by quadlet accesses per IEEE 1394 clause 6.2.5.2.2.


This code was added after recommendation to set it explicitly in the
driver:
http://marc.info/?l=linux-scsi&m=120137366708017
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/11424

It is probably not going to happen that somebody decreases the SCSI
default.  But perhaps we should still keep this explicit...?

[PATCH 4/4] firewire: sbp2: remove overzealous alignment constraints

Clemens Ladisch — 2012-05-18T16:42:05

The SBP-2/3 specifications do not require any alignment of data
buffers; only their own data structures need to be quadlet-aligned.

This patch is perfectly safe because there is no actual change:
the SCSI framework uses a default block queue DMA alignment of
32 bits anyway.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 drivers/firewire/sbp2.c |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
< at >< at > -207,9 +207,8 < at >< at > static const struct device *lu_dev(const struct sbp2_logical_unit *lu)
 #define SBP2_MAX_CDB_SIZE16

 /*
- * The default maximum s/g segment size of a FireWire controller is
- * usually 0x10000, but SBP-2 only allows 0xffff. Since buffers have to
- * be quadlet-aligned, we set the length limit to 0xffff & ~3.
+ * The maximum SBP-2 data buffer size is 0xffff.  We quadlet-align this
+ * for compatibility with earlier versions of this driver.
  */
 #define SBP2_MAX_SEG_SIZE0xfffc

< at >< at > -1530,9 +1529,6 < at >< at > static int sbp2_scsi_slave_alloc(struct scsi_device *sdev)

 sdev->allow_restart = 1;

-/* SBP-2 requires quadlet alignment of the data buffers. */
-blk_queue_update_dma_alignment(sdev->request_queue, 4 - 1);
-
 if (lu->tgt->workarounds & SBP2_WORKAROUND_INQUIRY_36)
 sdev->inquiry_len = 36;


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH 3/4] firewire: sbp2: remove superfluousblk_queue_max_segment_size() call

Clemens Ladisch — 2012-05-18T16:41:28

The SCSI framework automatically initializes the block queue's segment
size with the DMA device's segment size.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 drivers/firewire/sbp2.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
< at >< at > -1564,8 +1564,6 < at >< at > static int sbp2_scsi_slave_configure(struct scsi_device *sdev)
 if (lu->tgt->workarounds & SBP2_WORKAROUND_128K_MAX_TRANS)
 blk_queue_max_hw_sectors(sdev->request_queue, 128 * 1024 / 512);

-blk_queue_max_segment_size(sdev->request_queue, SBP2_MAX_SEG_SIZE);
-
 return 0;
 }


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH 2/4] firewire: sbp2: use scsi_dma_(un)map

Clemens Ladisch — 2012-05-18T16:40:19

Use the scsi_dma_map/scsi_dma_unmap helper to simplify the code
a little.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 drivers/firewire/sbp2.c |   13 ++++---------
 1 files changed, 4 insertions(+), 9 deletions(-)

--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
< at >< at > -1296,10 +1296,7 < at >< at > static struct fw_driver sbp2_driver = {
 static void sbp2_unmap_scatterlist(struct device *card_device,
    struct sbp2_command_orb *orb)
 {
-if (scsi_sg_count(orb->cmd))
-dma_unmap_sg(card_device, scsi_sglist(orb->cmd),
-     scsi_sg_count(orb->cmd),
-     orb->cmd->sc_data_direction);
+scsi_dma_unmap(orb->cmd);

 if (orb->request.misc & cpu_to_be32(COMMAND_ORB_PAGE_TABLE_PRESENT))
 dma_unmap_single(card_device, orb->page_table_bus,
< at >< at > -1405,9 +1402,8 < at >< at > static int sbp2_map_scatterlist(struct sbp2_command_orb *orb,
 struct scatterlist *sg = scsi_sglist(orb->cmd);
 int i, n;

-n = dma_map_sg(device->card->device, sg, scsi_sg_count(orb->cmd),
-       orb->cmd->sc_data_direction);
-if (n == 0)
+n = scsi_dma_map(orb->cmd);
+if (n <= 0)
 goto fail;

 /*
< at >< at > -1453,8 +1449,7 < at >< at > static int sbp2_map_scatterlist(struct sbp2_command_orb *orb,
 return 0;

  fail_page_table:
-dma_unmap_sg(device->card->device, scsi_sglist(orb->cmd),
-     scsi_sg_count(orb->cmd), orb->cmd->sc_data_direction);
+scsi_dma_unmap(orb->cmd);
  fail:
 return -ENOMEM;
 }

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH 1/4] firewire: sbp2: give correct DMA device to scsi framework

Clemens Ladisch — 2012-05-18T16:39:39

The sbp2 driver does DMA not on the unit but on the card device.

The driver worked even with the wrong device because at the moment, it
happens to reimplement the DMA functions of the SCSI framework.

Signed-off-by: Clemens Ladisch <clemens< at >ladisch.de>
---
 drivers/firewire/sbp2.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

--- a/drivers/firewire/sbp2.c
+++ b/drivers/firewire/sbp2.c
< at >< at > -1163,7 +1163,8 < at >< at > static int sbp2_probe(struct device *dev)

 shost->max_cmd_len = SBP2_MAX_CDB_SIZE;

-if (scsi_add_host(shost, &unit->device) < 0)
+if (scsi_add_host_with_dma(shost, &unit->device,
+   device->card->device) < 0)
 goto fail_shost_put;

 /* implicit directory ID */

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

[PATCH 0/4] various SBP-2 DMA cleanups

Clemens Ladisch — 2012-05-18T16:38:20

 drivers/firewire/sbp2.c |   26 ++++++++------------------
 1 file changed, 8 insertions(+), 18 deletions(-)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [Bug 43244] New: firewire_ohci prevents boot

Clemens Ladisch — 2012-05-16T13:53:29

For Ubuntu, see <https://wiki.ubuntu.com/KernelTeam/GitKernelBuild>.

To enable PCI debugging, enable the configuration options
CONFIG_DEBUG_KERNEL and CONFIG_PCI_DEBUG.


Regards,
Clemens

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

RE: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can'twork (Register access failure)

Jennifer Li (TP — 2012-05-16T10:33:44

Hi Stefan Richter,

Thanks for your reply. This is my test result. Please see the below.

OS: Fedora 16
Kernel version: 3.1.07 & 3.4 rc6

Best regards,
Jennifer
-----Original Message-----
From: Stefan Richter [mailto:stefanr< at >s5r6.in-berlin.de] 
Sent: Tuesday, May 15, 2012 3:24 PM
To: Jennifer Li (TP)
Cc: linux1394-devel< at >lists.sourceforge.net; Ayan George; Anael; Clemens
Ladisch
Subject: Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device
can't work (Register access failure)

http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394.git;a=short
log;h=refs/heads/o2micro
[Jennifer]
Please see the attached picture "screenshot.png".
I have tried to add the " options firewire-ohci cycle_timer_hard_fail=0
sclk_retries=0" in the conf files under "/etc/modprobe.d/". After that,
reboot it. 

time
[Jennifer]
Please see the attached file ochi.c.
I have added the patch on ohci.c. (without the solution (A) )


On May 15 bugzilla-daemon< at >bugzilla.kernel.org wrote:
02:24:16 ---

If
  - neither clearing regAccessFail after cycleTimer access
  - nor avoiding cycleTimer access altogether (at least until
applications
    need it, which would be typically not before an A/V device was
    connected)
does help here, then that's disappointing but not entirely surprising...

But just to confirm that I understood correctly:  You succeeded to patch
and load the drivers alternatively with the patches from (a) or just the
single patch from (b), but the problem persisted, right?

[Jennifer]
I have test the single solution only. The problems was persisted.

[Or was it impossible to modify the kernel, based on the rather sparse
information behind the links?  Ayan George has a kernel package which is
modified according to (a); maybe he and I could extend this such that
the
modprobe options are already set to =0 and that Ayan can also upload a
kernel which incorporates (b) if need be.]



I am not sure, not even what the problem source is.

  - Do our drivers miss to initialize the physical layer part of the
    controller in some way?  There is a tool from Clemens Ladisch which
    can show PHY register contents; let me get back to you with
    instructions how to compile this tool and how to collect possibly
    relevant information with it.

  - Or is the problem source at the 1394 link layer rather than PHY
layer?
    I don't have an idea at this point how to find out.

  - Or is it about the PCIe interface?

  - Or maybe a bad interaction between initialization of the 1394
    controller function with that of the flash memory card controller
    functions?

Both the observed behavior (1394 controller only works properly if an
external node is connected before controller initialization) and the
regAccessFail message hint that it is a PHY problem.  But some details
of
the malfunction without prior connected external node according to
logs from earlier discussions (selfID, AT-req, AR-resp appear to work,
physical response or AR-req don't work) rather speak for a higher level
problem.

Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can'twork (Register access failure)

Ayan George — 2012-05-16T10:37:25

I'll try to get this to you this afternoon.

-ayan

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can'twork (Register access failure)

Stefan Richter — 2012-05-15T07:24:07


On May 15 bugzilla-daemon< at >bugzilla.kernel.org wrote:

If
  - neither clearing regAccessFail after cycleTimer access
  - nor avoiding cycleTimer access altogether (at least until applications
    need it, which would be typically not before an A/V device was
    connected)
does help here, then that's disappointing but not entirely surprising...

But just to confirm that I understood correctly:  You succeeded to patch
and load the drivers alternatively with the patches from (a) or just the
single patch from (b), but the problem persisted, right?

[Or was it impossible to modify the kernel, based on the rather sparse
information behind the links?  Ayan George has a kernel package which is
modified according to (a); maybe he and I could extend this such that the
modprobe options are already set to =0 and that Ayan can also upload a
kernel which incorporates (b) if need be.]



I am not sure, not even what the problem source is.

  - Do our drivers miss to initialize the physical layer part of the
    controller in some way?  There is a tool from Clemens Ladisch which
    can show PHY register contents; let me get back to you with
    instructions how to compile this tool and how to collect possibly
    relevant information with it.

  - Or is the problem source at the 1394 link layer rather than PHY layer?
    I don't have an idea at this point how to find out.

  - Or is it about the PCIe interface?

  - Or maybe a bad interaction between initialization of the 1394
    controller function with that of the flash memory card controller
    functions?

Both the observed behavior (1394 controller only works properly if an
external node is connected before controller initialization) and the
regAccessFail message hint that it is a PHY problem.  But some details of
the malfunction without prior connected external node according to
logs from earlier discussions (selfID, AT-req, AR-resp appear to work,
physical response or AR-req don't work) rather speak for a higher level
problem.

[Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work(Register access failure)

Stefan Richter — 2012-05-14T06:44:21

Current discussion:
http://marc.info/?t=133346965500001

Potential solutions, not yet fully confirmed:

(a) After the CycleTimer acces in ohci_enable(), clear regAccessFail and
proceed with controller initialization.
Patch series:
http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394.git;a=shortlog;h=refs/heads/o2micro
Configure a file in /etc/modprobe.d/ with the line:
options firewire-ohci cycle_timer_hard_fail=0 sclk_retries=0

Or

(b) Defer ohci->bus_time initialization and updates until the bus time CSR
is accessed for the first time.
Patch:
http://marc.info/?l=linux1394-devel&m=133611307930958

----------------

At this point, we especially need someone to test this latter patch and to
check
  - whether this gets the sequence "boot with firewire-ohci automatically
    loaded -> plug in 1394 device -> access device" to work,
  - whether this makes suspend/ resume work repeatedly (Linux does not hang
    during suspend or resume without 1394 device connected; 1394 device can
    be plugged in and accessed after resume; 1394 device can be plugged in
    before suspend and still be accessed after resume).

Re: [Bug 43244] New: firewire_ohci prevents boot

Stefan Richter — 2012-05-13T20:13:57

Rob,

thanks for the report. Here is the full quote for the list to know.
Some comments at the end.

On May 13 bugzilla-daemon< at >bugzilla.kernel.org wrote:

The controller is according to the attachment:
0a:09.0 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 21)
0a:09.1 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 21)
0a:09.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) (prog-if 10 [OHCI])
Subsystem: Acer Incorporated [ALI] Device 0092

$ git shortlog v3.1-rc2..v3.1-rc3 drivers/firewire/
Linus Torvalds (2):
Merge branch 'fixes' of git://git.kernel.org/.../ieee1394/linux1394-2.6
Merge branch 'fixes' of git://git.kernel.org/.../ieee1394/linux1394-2.6

Stefan Richter (3):
firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases
firewire: ohci: fix DMA unmapping in an error path
firewire: core: handle ack_busy when fetching the Config ROM

None of that code is in the path that is taken up to and after "failed to
set Link Power Status". Hence the bug was most certainly not introduced
by these but
- either outside v3.1-rc2..v3.1-rc3, and the bisection went wrong
due to a false negative,
- or inside v3.1-rc2..v3.1-rc3 but due to some changes to the kernel
or to the kernel configuration that are not directly related to
firewire.

After "failed to set Link Power Status", firewire-ohci just frees memory
which it allocated up to that. Could be that we have a mistake there but
I doubt it.

Not sure how to proceed from here on.

PS:
I am Cc'ing bugzilla-daemon< at >bugzilla.kernel.org but I suspect that
commenting by mail does not work anymore at bugzilla.kernel.org. Let's see.

For future reference: Do not /report/ kernel bugs at the kernel bug tracker.
It is not for bug reporting. It is for bug /tracking/, and pretty bad even
at that. Report kernel bugs at the kernel mailing lists. Almost all of them
are open for postings without prior subscription.