1. 09 Jan, 2014 1 commit
  2. 12 Dec, 2013 1 commit
  3. 04 Aug, 2013 1 commit
  4. 30 Apr, 2013 4 commits
    • Peter Hurley's avatar
      firewire: ohci: dump_stack() for PHY regs read/write failures · 6fe9efb9
      Peter Hurley authored
      A stack trace is an invaluable tool in determining the basis
      and cause of PHY regs read/write failures.
      Include PHY reg addr (and value for writes) in the diagnostic.
      [Stefan R:  changed whitespace]
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Peter Hurley's avatar
      firewire: ohci: Improve bus reset error messages · 67672134
      Peter Hurley authored
      Many of the error messages possible from bus_reset_work() do not
      contain enough information to distinguish which error condition
      occurred nor enough information to evaluate the error afterwards.
      Differentiate all error conditions in bus_reset_work(); add
      additional information to make error diagnosis possible.
      [Stefan R:  fixed self-ID endian conversion]
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Peter Hurley's avatar
      firewire: ohci: Alias dev_* log functions · de97cb64
      Peter Hurley authored
      Convert dev_xxxx(ohci->card.device, ...) log functions to
      ohci_xxxx(ohci, ...).
      [Stefan R:  Peter argues that this increases readability of the code.]
      [Stefan R:  changed whitespace]
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Peter Hurley's avatar
      firewire: ohci: Fix 'failed to read phy reg' on FW643 rev8 · bd972688
      Peter Hurley authored
      With the LSI FW643 rev 8 [1], the first commanded bus reset at
      the conclusion of ohci_enable() has been observed to fail with
      the following messages:
      [    4.884015] firewire_ohci 0000:01:00.0: failed to read phy reg
      [    5.684012] firewire_ohci 0000:01:00.0: failed to read phy reg
      With drivers/firewire/ohci.c instrumented, the error condition [2]
      indicates the PHY arbitration state machine has timed out prior to
      enabling PHY LCtrl.
      Furthermore, instrumenting ohci_enable() shows that LPS has been
      enabled within 1 ms.
      Test LPS latching every 1 ms rather than every 50ms.
      [1]  lspci -v
      01:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08) (prog-if 10 [OHCI])
      	Subsystem: LSI Corporation FW643 [TrueFire] PCIe 1394b Controller
      	Flags: bus master, fast devsel, latency 0, IRQ 92
      	Memory at fbeff000 (64-bit, non-prefetchable) [size=4K]
      	Capabilities: [44] Power Management version 3
      	Capabilities: [4c] MSI: Enable+ Count=1/1 Maskable- 64bit+
      	Capabilities: [60] Express Endpoint, MSI 00
      	Capabilities: [100] Advanced Error Reporting
      	Capabilities: [140] Virtual Channel
      	Capabilities: [170] Device Serial Number 08-14-43-82-00-00-41-fc
      	Kernel driver in use: firewire_ohci
      	Kernel modules: firewire-ohci
      [2] instrumented WARNING in read_phy_reg()
      [    4.576010] ------------[ cut here ]------------
      [    4.576035] WARNING: at ./drivers/firewire/ohci.c:570 read_phy_reg+0x93/0xe0 [firewire_ohci]()
      [    4.576050] Hardware name: Precision WorkStation T5400
      [    4.576058] failed to read phy reg:1 (phy(5) @ config enhance:19)
      [    4.576068] Modules linked in: hid_logitech_dj hid_generic(+) usbhid <...snip...>
      [    4.576140] Pid: 61, comm: kworker/2:1 Not tainted 3.8.0-2+fwtest-xeon #2+fwtest
      [    4.576149] Call Trace:
      [    4.576160]  [<ffffffff8105468f>] warn_slowpath_common+0x7f/0xc0
      [    4.576168]  [<ffffffff81054786>] warn_slowpath_fmt+0x46/0x50
      [    4.576178]  [<ffffffffa00caca3>] read_phy_reg+0x93/0xe0 [firewire_ohci]
      [    4.576188]  [<ffffffffa00cae19>] ohci_read_phy_reg+0x39/0x60 [firewire_ohci]
      [    4.576203]  [<ffffffffa00731ff>] fw_send_phy_config+0xbf/0xe0 [firewire_core]
      [    4.576214]  [<ffffffffa006b2d6>] br_work+0x46/0xb0 [firewire_core]
      [    4.576225]  [<ffffffff81071e0c>] process_one_work+0x13c/0x500
      [    4.576238]  [<ffffffffa006b290>] ? fw_card_initialize+0x180/0x180 [firewire_core]
      [    4.576248]  [<ffffffff810737ed>] worker_thread+0x16d/0x470
      [    4.576257]  [<ffffffff81073680>] ? busy_worker_rebind_fn+0x100/0x100
      [    4.576266]  [<ffffffff8107d160>] kthread+0xc0/0xd0
      [    4.576275]  [<ffffffff816a0000>] ? pcpu_dump_alloc_info+0x1cb/0x2c4
      [    4.576284]  [<ffffffff8107d0a0>] ? kthread_create_on_node+0x130/0x130
      [    4.576297]  [<ffffffff816b2f6c>] ret_from_fork+0x7c/0xb0
      [    4.576305]  [<ffffffff8107d0a0>] ? kthread_create_on_node+0x130/0x130
      [    4.576313] ---[ end trace cbc940994b300302 ]---
      [Stefan R:  Peter also reports a change of behavior with LSI FW323.
      Before the patch, there would often occur a lock transaction failure
      during firewire-core startup:
      [    6.056022] firewire_core 0000:07:06.0: BM lock failed (timeout), making local node (ffc0) root
      This failure no longer happens after the patch, without an obvious
      reason for the failure or the fix.]
      [Stefan R:  Added quirk flag, quirk table entry, and comment.]
      Reported-by: default avatarTim Jordan <tim@insipid.org.uk>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  5. 28 Apr, 2013 7 commits
    • Andy Leiserson's avatar
      firewire: ohci: fix VIA VT6306 video reception · be8dcab9
      Andy Leiserson authored
      Add quirk for VT6306 wake bit behavior.
      VT6306 seems to reread the wrong descriptor when the wake bit is
      written. work around by putting a copy of the branch address in the
      first descriptor of the block.
      [Stefan R:  This fixes the known broken video reception via gstreamer
      on VIA VT6306.  100% repeatable testcase:
      $ gst-launch-0.10 dv1394src \! dvdemux \! dvdec \! xvimagesink
      with a camcorder or other DV source connected.  Likewise for MPEG2-TS
      reception via gstreamer, e.g. from TV settop boxes.
      Perhaps this also fixes dv4l on VT6306, but this is as yet untested.
      Kino, dvgrab or FFADO had not been affected by this chip quirk.
      Additional comments from Andy:]
      I've looked into some problems with the wake bit on a vt6306 family
      chip (1106:3044, rev 46).
      I used this firewire card in a mythtv setup (ISO receive MPEG2 stream)
      with Debian 2.6.32 kernels for ~2 years without problems.
      Since upgrading to 3.2, I've been having problems with the input stream
      freezing -- input data stops until I restart mythtv (I expect closing
      and reopening the device would be sufficient). This happens
      infrequently, maybe one out of 20 recordings. I eventually determined
      that the problem is more likely to occur if the system is loaded.
      I isolated the kernel version as the triggering SW factor and then
      specifically the change from dualbuffer back to packet-per-buffer DMA
      The possibility that the controller does not properly respond to the
      wake bit was suggested in
      https://bugzilla.redhat.com/show_bug.cgi?id=415841, but not proven.
      Based on the fact that dualbuffer mode worked while packet-per-buffer
      has trouble, I guessed that upon seeing the wake bit written, the vt6306
      controller only checks the branch address in the first descriptor of the
      block, even if that is not the correct place to look (because the block
      has multiple descriptors).
      This theory seems to be correct. When the ISO reception is hung, I am
      able to resume it by manually writing the branch address to the first
      descriptor in the block, and then writing the wake bit.
      I've had luck so far with the attached patch, so I'm including it. It's
      probably not a complete solution -- I haven't tested transmit modes to
      see whether they have a similar issue.
      I doubt that the quirk test is any cheaper than just writing the extra
      branch address in all cases, but it does reduce the risk of breaking
      other hardware.
      [Stefan R:  omitted QUIRK_NO_MSI from VT6306 quirks table entry,
      changed whitespace]
      Signed-off-by: default avatarAndy Leiserson <andy@leiserson.org>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Peter Hurley's avatar
      firewire: ohci: Check LPS before register access on pci removal · 8db49149
      Peter Hurley authored
      A pci device can be removed while in its suspended state. If the ohci
      host controller is suspended, the PHY is also in low-power mode and
      LPS is disabled. If LPS is disabled, most of the host registers aren't
      accessible, including IntMaskClear. Furthermore, access to these registers
      when LPS is disabled can cause hard lockups on some hardware. Since
      interrupts are already disabled in this mode, further action is
      Test LPS before attempting to write IntMaskClear to disable interrupts.
      [Stefan R: whitespace changes]
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Peter Hurley's avatar
      firewire: ohci: Fix double free_irq() · 247fd50b
      Peter Hurley authored
      A pci device can be removed while in its suspended state.
      Because the ohci driver freed the irq to suspend, free_irq() is
      called twice; once from pci_remove() and again from pci_suspend(),
      which issues the warning below [1].
      Rather than allocate the irq in the .enable() path, move the
      allocation to .probe(). Consequently, the irq is not reallocated
      upon pci_resume() and thus is not freed upon pci_suspend().
      [1] Warning reported by Mark Einon <mark.einon@gmail.com> when
      suspending an MSI MS-1727 GT740 laptop on Ubuntu 3.5.0-22-generic
      WARNING: at ./kernel/irq/manage.c:1198 __free_irq+0xa3/0x1e0()
      Hardware name: MS-1727
      Trying to free already-free IRQ 16
      Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables <...snip...>
      Pid: 4, comm: kworker/0:0 Tainted: P           O 3.5.0-22-generic #34-Ubuntu
      Call Trace:
       [<ffffffff81051c1f>] warn_slowpath_common+0x7f/0xc0
       [<ffffffff81051d16>] warn_slowpath_fmt+0x46/0x50
       [<ffffffff8103fa39>] ? default_spin_lock_flags+0x9/0x10
       [<ffffffff810df6b3>] __free_irq+0xa3/0x1e0
       [<ffffffff810df844>] free_irq+0x54/0xc0
       [<ffffffffa005a27e>] pci_remove+0x6e/0x210 [firewire_ohci]
       [<ffffffff8135ae7f>] pci_device_remove+0x3f/0x110
       [<ffffffff8141fdbc>] __device_release_driver+0x7c/0xe0
       [<ffffffff8141fe4c>] device_release_driver+0x2c/0x40
       [<ffffffff8141f5f1>] bus_remove_device+0xe1/0x120
       [<ffffffff8141cd1a>] device_del+0x12a/0x1c0
       [<ffffffff8141cdc6>] device_unregister+0x16/0x30
       [<ffffffff81354784>] pci_stop_bus_device+0x94/0xa0
       [<ffffffffa0091c67>] acpiphp_disable_slot+0xb7/0x1a0 [acpiphp]
       [<ffffffffa0090716>] ? get_slot_status+0x46/0xc0 [acpiphp]
       [<ffffffffa0091d7d>] acpiphp_check_bridge.isra.15+0x2d/0xf0 [acpiphp]
       [<ffffffffa0092442>] _handle_hotplug_event_bridge+0x372/0x4d0 [acpiphp]
       [<ffffffff81390f8c>] ? acpi_os_execute_deferred+0x2f/0x34
       [<ffffffff8116e22d>] ? kfree+0xed/0x110
       [<ffffffff8107086a>] process_one_work+0x12a/0x420
       [<ffffffffa00920d0>] ? _handle_hotplug_event_func+0x1d0/0x1d0 [acpiphp]
       [<ffffffff8107141e>] worker_thread+0x12e/0x2f0
       [<ffffffff810712f0>] ? manage_workers.isra.26+0x200/0x200
       [<ffffffff81075f13>] kthread+0x93/0xa0
       [<ffffffff8168d024>] kernel_thread_helper+0x4/0x10
       [<ffffffff81075e80>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff8168d020>] ? gs_change+0x13/0x13
      Reported-by: default avatarMark Einon <mark.einon@gmail.com>
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: remove unnecessary alloc/OOM messages · cfb0c9d1
      Stefan Richter authored
      These are redundant to log messages from the mm core.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: sbp2: replace BUG_ON by WARN_ON · d6c8cefc
      Stefan Richter authored
      No need to crash and burn if S/G element sizes cannot be set to our
      liking; just leave a message in the log.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: core: remove an always false test · bdabfa54
      Stefan Richter authored
      struct fw_cdev_allocate_iso_resource.bandwidth is unsigned.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Paul Bolle's avatar
      firewire: Remove two unneeded checks for macros · df7ce663
      Paul Bolle authored
      The old IEEE 1394 driver stack was removed in v2.6.37. That made the
      checks for two Kconfig (module) macros unneeded, since they will now
      always evaluate to true. Remove these two checks.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  6. 28 Mar, 2013 1 commit
    • Simon Horman's avatar
      net: add ETH_P_802_3_MIN · e5c5d22e
      Simon Horman authored
      Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
      an 802.3 frame. Frames with a lower value in the ethernet type field
      are Ethernet II.
      Also update all the users of this value that David Miller and
      I could find to use the new constant.
      Also correct a bug in util.c. The comparison with ETH_P_802_3_MIN
      should be >= not >.
      As suggested by Jesse Gross.
      Compile tested only.
      Cc: David Miller <davem@davemloft.net>
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: John W. Linville <linville@tuxdriver.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Bart De Schuymer <bart.de.schuymer@pandora.be>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: linux-bluetooth@vger.kernel.org
      Cc: netfilter-devel@vger.kernel.org
      Cc: bridge@lists.linux-foundation.org
      Cc: linux-wireless@vger.kernel.org
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: linux-media@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Cc: dev@openvswitch.org
      Acked-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Acked-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 26 Mar, 2013 6 commits
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection. · 6752c8db
      YOSHIFUJI Hideaki / 吉藤英明 authored
      Inspection of upper layer protocol is considered harmful, especially
      if it is about ARP or other stateful upper layer protocol; driver
      cannot (and should not) have full state of them.
      IPv4 over Firewire module used to inspect ARP (both in sending path
      and in receiving path), and record peer's GUID, max packet size, max
      speed and fifo address.  This patch removes such inspection by extending
      our "hardware address" definition to include other information as well:
      max packet size, max speed and fifo.  By doing this, The neighbour
      module in networking subsystem can cache them.
      Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
            information will not be used in the driver when sending.
      When a packet is being sent, the IP layer fills our pseudo header with
      the extended "hardware address", including GUID and fifo.  The driver
      can look-up node-id (the real but rather volatile low-level address)
      by GUID, and then the module can send the packet to the wire using
      parameters provided in the extendedn hardware address.
      This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
      over IEEE1394 (RFC3146) share same "hardware address" format
      in their address resolution protocols.
      Here, extended "hardware address" is defined as follows:
      union fwnet_hwaddr {
      	u8 u[16];
      	struct {
      		__be64 uniq_id;		/* EUI-64			*/
      		u8 max_rec;		/* max packet size		*/
      		u8 sspd;		/* max speed			*/
      		__be16 fifo_hi;		/* hi 16bits of FIFO addr	*/
      		__be32 fifo_lo;		/* lo 32bits of FIFO addr	*/
      	} __packed uc;
      Note that Hardware address is declared as union, so that we can map full
      IP address into this, when implementing MCAP (Multicast Cannel Allocation
      Protocol) for IPv6, but IP and ARP subsystem do not need to know this
      format in detail.
      One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
      is that 1394 ARP Request/Reply do not contain the target hardware address
      field (aka ar$tha).  This difference is handled in the ARP subsystem.
      CC: Stephan Gatzka <stephan.gatzka@gmail.com>
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      firewire net: Ignore spd and max_payload advertised by ARP. · 61a7839a
      YOSHIFUJI Hideaki / 吉藤英明 authored
      Stefan Richter <stefanr@s5r6.in-berlin.de> says:
      | As far as I can tell, it would be best to ignore max_rec and sspd from ARP
      | and NDP but keep using the respective information from firewire-core
      | instead (handed over by fwnet_probe()).
      | Why?  As I noted earlier, RFC 2734:1999 and RFC 3146:2001 were apparently
      | written with a too simplistic notion of IEEE 1394 bus topology, resulting
      | in max_rec and sspd in ARP-1394 and NDP-1394 to be useless, IMO.
      | Consider a bus like this:
      |     A ---- B ==== C
      | A, B, C are all IP-over-1394 capable nodes.  ---- is an S400 cable hop,
      | and ==== is an S800 cable hop.
      | In case of unicasts or multicasts in which node A is involved as
      | transmitter or receiver, as well as in case of broadcasts, the speeds
      | S100, S200, S400 work and speed S400 is optimal.
      | In case of anything else, IOW in case of unicasts or multicasts in which
      | only nodes B and C are involved, the speeds S100, S200, S400, S800 work
      | and speed S800 is optimal.
      | Clearly, node A should indicate sspd = S400 in its ARP or NDP packets.
      | But which sspd should nodes B and C set there?  Maybe they set S400, which
      | would work but would waste half of the available bandwidth in the second
      | case.  Or maybe they set S800, which is OK in the second case but would
      | prohibit any communication with node A if blindly taken for correct.
      | On the other hand, firewire-core *always* gives us the correct and optimum
      | peer-to-peer speed and asynchronous packet payload, no matter how simple
      | or complex the bus topology is and no matter in which temporal order nodes
      | join the bus and are discovered.
      CC: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      firewire net: Allocate address handler before registering net_device. · 382c4b40
      YOSHIFUJI Hideaki / 吉藤英明 authored
      Allocate FIFO address before registering net_device.
      This is preparation to change the pseudo hardware address format
      for firewire devices to include the offset of the FIFO for receipt
      of unicast datagrams, instead of mangling ARP/NDP messages in the
      driver layer.
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      firewire net: Send L2 multicast via GASP. · 021b97e4
      YOSHIFUJI Hideaki / 吉藤英明 authored
      Send L2 multicast packet via GASP (Global asynchronous stream packet) by
      seeing the multicast bit in the L2 hardware address, not by seeing upper-
      layer protocol address.
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
  8. 13 Mar, 2013 11 commits
  9. 28 Feb, 2013 3 commits
  10. 21 Jan, 2013 2 commits
  11. 09 Jan, 2013 1 commit
  12. 03 Dec, 2012 1 commit
  13. 02 Dec, 2012 1 commit
    • Stephan Gatzka's avatar
      firewire: net: Fix handling of fragmented multicast/broadcast packets. · 9d237342
      Stephan Gatzka authored
      This patch fixes both the transmit and receive portion of sending
      fragmented mutlicast and broadcast packets.
      The transmit section was broken because the offset for INTFRAG and
      LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which
      was reserved with skb_push() in fwnet_send_packet).
      The receive section was broken because in fwnet_incoming_packet is a call
      to fwnet_peer_find_by_node_id(). Called with generation == -1 it will
      not find a peer and the partial datagrams are associated to a peer.
      [Stefan R:  The fix to use context->card->generation is not perfect.
      It relies on the IR tasklet which processes packets from the prior bus
      generation to run before the self-ID-complete worklet which sets the
      current card generation.  Alas, there is no simple way of a race-free
      implementation.  Let's do it this way for now.]
      Signed-off-by: default avatarStephan Gatzka <stephan.gatzka@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>