Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 10 5月, 2012 2 次提交
    • C
      firewire: Move fw_card kref functions into linux/firewire.h · fc5f80b1
      由 Chris Boot 提交于 
      When writing a firewire driver that doesn't deal with struct fw_device
objects (e.g. it only publishes FireWire units and doesn't subscribe to
them), you likely need to keep referenced to struct fw_card objects so
that you can send messages to other nodes. This patch moves
fw_card_put(), fw_card_get() and fw_card_release() into the public
include/linux/firewire.h header instead of drivers/firewire/core.h, and
adds EXPORT_SYMBOL_GPL(fw_card_release).

The firewire-sbp-target module requires these so it can keep a reference
to the fw_card object in order that it can fetch ORBs to execute and
read/write related data and status information.
Signed-off-by: NChris Boot <bootc@bootc.net>
Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      fc5f80b1
    • C
      firewire: Add function to get speed from opaque struct fw_request · 253d9237
      由 Chris Boot 提交于 
      Sometimes it's useful to know the FireWire speed of the request that has
just come in to a fw_address_handler callback. As struct fw_request is
opaque we can't peek inside to get the speed out of the struct fw_packet
that's just inside. For example, the SBP-2 spec says:

"The speed at which the block write request to the MANAGEMENT_AGENT
register is received shall determine the speed used by the target for
all subsequent requests to read the initiator’s configuration ROM, fetch
ORB’s from initiator memory or store status at the initiator’s
status_FIFO. Command block ORB’s separately specify the speed for
requests addressed to the data buffer or page table."

[ ANSI T10/1155D Revision 4 page 53/54 ]
Signed-off-by: NChris Boot <bootc@bootc.net>
Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      253d9237
  3. 29 3月, 2012 1 次提交
  5. 19 3月, 2012 7 次提交
  7. 17 3月, 2012 1 次提交
    • C
      firewire: ohci: fix too-early completion of IR multichannel buffers · 0c0efbac
      由 Clemens Ladisch 提交于 
      handle_ir_buffer_fill() assumed that a completed descriptor would be
indicated by a non-zero transfer_status (as in most other descriptors).
However, this field is written by the controller as soon as (the end of)
the first packet has been written into the buffer.  As a consequence, if
we happen to run into such a descriptor when the interrupt handler is
executed after such a packet has completed, the descriptor would be
taken out of the list of active descriptors as soon as the buffer had
been partially filled, so the event for the buffer being completely
filled would never be sent.

To fix this, handle descriptors only when they have been completely
filled, i.e., when res_count == 0.  (This also matches the condition
that is reported by the controller with an interrupt.)
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      0c0efbac
  9. 11 3月, 2012 3 次提交
  11. 23 2月, 2012 11 次提交
    • C
      firewire: sbp2: Fix SCSI sense data mangling · 6503de65
      由 Chris Boot 提交于 
      SCSI sense data in SBP-2/3 is carried in an unusual format that means we
have to un-mangle it on our end before we pass it to the SCSI subsystem.
Currently our un-mangling code doesn't quite follow the SBP-2 standard
in that we always assume Current and never Deferred error types, we
never set the VALID bit, and we mishandle the FILEMARK, EOM and ILI
bits.

This patch fixes the sense un-mangling to correctly handle those and
follow the spec.
Signed-off-by: NChris Boot <bootc@bootc.net>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      6503de65
    • C
      firewire: sbp2: Ignore SBP-2 targets on the local node · 74044563
      由 Chris Boot 提交于 
      The firewire-sbp2 module tries to login to an SBP-2/3 target even when
it is running on the local node, which fails because of the inability to
fetch data from DMA mapped regions using firewire transactions on the
local node. It also doesn't make much sense to have the initiator and
target on the same node, so this patch prevents this behaviour.
Signed-off-by: NChris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changed the comment)
      74044563
    • C
      firewire: sbp2: Take into account Unit_Unique_ID · 8ff6a757
      由 Chris Boot 提交于 
      If the target's unit directory contains a Unit_Unique_ID entry, we
should use that as the target's GUID for identification purposes. The
SBP-2 standards document says:

"Although the node unique ID (EUI-64) present in the bus information
block is sufficient to uniquely identify nodes attached to Serial Bus,
it is insufficient to identify a target when a vendor implements a
device with multiple Serial Bus node connections. In this case initiator
software requires information by which a particular target may be
uniquely identified, regardless of the Serial Bus access path used."

[ IEEE T10 P1155D Revision 4, Section 7.6 (page 51) ] and
[ IEEE T10 P1467D Revision 5, Section 7.9 (page 74) ]
Signed-off-by: NChris Boot <bootc@bootc.net>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      8ff6a757
    • S
      firewire: nosy: Use the macro DMA_BIT_MASK(). · e894d1d7
      由 santosh nayak 提交于 
      Use the macro DMA_BIT_MASK instead of the constant  0xffffffff
Signed-off-by: NSantosh Nayak <santoshprasadnayak@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e894d1d7
    • S
      firewire: core: convert AR-req handler lock from _irqsave to _bh · ea102d0e
      由 Stefan Richter 提交于 
      fw_core_handle_request() is called by the low-level driver in tasklet
context or process context, and fw_core_add/remove_address_handler() is
called by mid- or high-level code in process context.  So convert
address_handler_lock accesses from those which disable local IRQs to
ones which just disable local softIRQs.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ea102d0e
    • S
      firewire: core: fix race at address_handler unregistration · 90963f1c
      由 Stefan Richter 提交于 
      Fix the following unlikely but possible race:

CPU 1                             CPU 2
------------------------------------------------------------------------
AR-request tasklet
    lookup handler
                                  unregister handler
				  free handler->callback_data or handler
    call handler->callback

The application which registered the handler has no way to stop nodes
sending new requests to their address range, hence cannot prevent this
race.

Fix it simply by extending the address_handler_lock-protected region
from only around the lookup to around both lookup and call.  We only
need to do so in the exclusive region handler; the FCP region handler
already holds the lock around the handler->callback call.

Alas this removes the current ability to execute the callback in
parallel on different CPUs if it was called for different FireWire cards
at the same time.  (For a single card, the handler is already
serialized.)  If this loss of a rather obscure feature is not tolerable,
a more complex fix would be required:  Add a handler reference counter;
wait in fw_core_remove_address_handler() for this conter to become zero.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      90963f1c
    • S
      firewire: core: remove obsolete comment · 280f64d4
      由 Stefan Richter 提交于 
      Target-like applications or peer-to-peer-like applications require the
global address handler registration which we have right now, or a per-
card registration.  And node lookup, while it would be nice to have,
would be impossible in the brief time between self-ID-complete event and
completion of firewire-core's topology scanning.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      280f64d4
    • S
      firewire: core: prefix log messages with card name · 26b4950d
      由 Stefan Richter 提交于 
      Associate all log messages from firewire-core with the respective card
because some people have more than one card.  E.g.
    firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
    firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
    firewire_core: created device fw0: GUID 0814438400000389, S800
    firewire_core: phy config: new root=ffc1, gap_count=5
    firewire_core: created device fw1: GUID 0814438400000388, S800
    firewire_core: created device fw2: GUID 0001d202e06800d1, S800
turns into
    firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
    firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
    firewire_core 0000:04:00.0: created device fw0: GUID 0814438400000389, S800
    firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5
    firewire_core 0000:05:00.0: created device fw1: GUID 0814438400000388, S800
    firewire_core 0000:04:00.0: created device fw2: GUID 0001d202e06800d1, S800

This increases the module size slightly; to keep this in check, turn the
former printk wrapper macros into functions.  Their implementation is
largely copied from driver core's dev_printk counterparts.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      26b4950d
    • S
      firewire: net: use dev_printk API · 8408dc1c
      由 Stefan Richter 提交于 
      Change the log line prefix from "firewire_net: " to "net firewire0: "
etc. for the case that several RFC 2734 interfaces are being used in the
same machine.

Note, the netdev_printk API is not very useful to firewire-net.
netdev_notice(net, "abc\n") would result in irritating messages like
"firewire_ohci 0000:0a:00.0: firewire0: abc".  Nor would a dev_printk on
the fw_unit.device to which firewire-net is being bound be useful,
because there are generally multiple ones of those per interface (from
all RFC 2734 peers on the bus, the local node being only one of them).

In the initialization message of each interface, log the PCI device
name of the card which is parent of the netdevice instead of the GUID
of the peer which was semi-randomly used to establish the netdevice.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      8408dc1c
    • S
      firewire: net: identify to driver core as "firewire_net", not "net" · 59759ff6
      由 Stefan Richter 提交于 
      On second thought, there is little reason to have driver name differ
from module name.  Therefore, change
    /sys/bus/firewire/drivers/net
    /sys/bus/firewire/devices/fw0.0/driver -> [...]/net
    /sys/module/firewire_net/drivers/firewire:net
to
    /sys/bus/firewire/drivers/firewire_net
    /sys/bus/firewire/devices/fw0.0/driver -> [...]/firewire_net
    /sys/module/firewire_net/drivers/firewire:firewire_net
It is redundant but consistent with firewire-sbp2's recently changed
driver name.

I don't see this anywhere used, so it should not matter either way.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      59759ff6
    • S
      firewire: sbp2: identify to driver core as "firewire_sbp2", not "sbp2" · 0c22ecde
      由 Stefan Richter 提交于 
      Commit eba9ebaa "firewire: sbp2: use dev_printk API" changed
messages from e.g.
    firewire_sbp2: fw3.0: logged in to LUN 0000 (0 retries)
to
    sbp2 fw3.0: logged in to LUN 0000 (0 retries)
because the driver calls itself as "sbp2" when registering with driver
core and with SCSI core.  This is of course confusing, so switch to the
name "firewire_sbp2" for driver core in order to match what lsmod and
/sys/module/ show.  So we are back to
    firewire_sbp2 fw3.0: logged in to LUN 0000 (0 retries)
in the kernel log.

This also changes
    /sys/bus/firewire/drivers/sbp2
    /sys/bus/firewire/devices/fw3.0/driver -> [...]/sbp2
    /sys/module/firewire_sbp2/drivers/firewire:sbp2
to
    /sys/bus/firewire/drivers/firewire_sbp2
    /sys/bus/firewire/devices/fw3.0/driver -> [...]/firewire_sbp2
    /sys/module/firewire_sbp2/drivers/firewire:firewire_sbp2

but "cat /sys/class/scsi_host/host27/proc_name" stays "sbp2" just in
case that proc_name is used by any userland.

The transport detection in lsscsi is not affected.  (Tested with lsscsi
version 0.25.)  Udev's /dev/disk/by-id and by-path symlinks are not
affected either.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      0c22ecde
  13. 31 1月, 2012 1 次提交
  15. 27 1月, 2012 1 次提交
  17. 16 1月, 2012 3 次提交
  19. 13 1月, 2012 1 次提交
  21. 01 11月, 2011 1 次提交
  23. 18 10月, 2011 2 次提交
    • C
      firewire: ohci: fix isochronous DMA synchronization · a572e688
      由 Clemens Ladisch 提交于 
      Add the dma_sync_single_* calls necessary to ensure proper cache
synchronization for isochronous data buffers on non-coherent
architectures.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      a572e688
    • C
      firewire: ohci: work around selfID junk due to wrong gap count · 32eaeae1
      由 Clemens Ladisch 提交于 
      If a device's firmware initiates a bus reset by setting the IBR bit in
PHY register 1 without resetting the gap count field to 63 (and without
having sent a PHY configuration packet beforehand), the gap count of
this node will remain at the old value after the bus reset and thus be
inconsistent with the gap count on all other nodes.

The bus manager is supposed to detect the inconsistent gap count values
in the self ID packets and correct them by issuing another bus reset.

However, if the buggy device happens to be the cycle master, and if it
sends a cycle start packet immediately after the bus reset (which is
likely after a long bus reset), then the time between the end of the
selfID phase and the start of the cycle start packet will be based on
the too-small gap count value, so this gap will be too short to be
detected as a subaction gap by the other nodes.  This means that the
cycle start packet will be assumed to be self ID data, and will be
stored after the actual self ID quadlets in the self ID buffer.

This garbage in the self ID buffer made firewire-core ignore all of the
self ID data, and thus prevented the Linux bus manager from correcting
the problem.  Furthermore, because the bus reset handling was aborted
completely, asynchronous transfers would be no longer handled correctly,
and fw_run_transaction() would hang until the next bus reset.

To fix this, make the detection of inconsistent self IDs more
discriminating:  If the invalid data in the self ID buffer looks like
a cycle start packet, we can assume that the previous data in the buffer
is correctly received self ID information, and process it normally.

(We inspect only the first quadlet of the cycle start packet, because
this value is different enough from any valid self ID quadlet, and many
controllers do not store the cycle start packet in five quadlets because
they expect self ID data to have an even number of quadlets.)

This bug has been observed when a bus-powered DesktopKonnekt6 is
switched off with its power button.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      32eaeae1
  25. 09 10月, 2011 4 次提交
  27. 17 9月, 2011 2 次提交