03 Feb, 2015
1 commit
-
The kernel was using the vendor ID 0xd00d1e, which was inherited from
the old ieee1394 driver stack. However, this ID was not registered, and
invalid.Instead, use the vendor/model IDs that are now officially assigned to
the kernel:
https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments[stefanr:
- The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at
IEEE Registration Authority.
- The range of model IDs 023900...0239ff are the Linux kernel 1394
subsystem's identifiers, registered at Openmoko.
- Model ID 023901 is picked by the subsystem developers as
firewire-core's model ID.]Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
20 Jan, 2014
1 commit
-
This makes all of a machine's memory accessible to remote debugging via
FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link
layer controllers.This requires actual support by the controller. The only ones currently
known to support it are Agere/LSI FW643. Most if not all other OHCI-1394
controllers do not implement the optional Physical Upper Bound register.
With them, RDMA will continue to be limited to the lowermost 4 GB.firewire-ohci's startup message in the kernel log is augmented to tell
whether the controller does expose more than 4 GB to RDMA.While OHCI-1394 allows for a maximum Physical Upper Bound of
0xffff'0000'0000 (near 256 TB), this implementation sets it to
0x8000'0000'0000 (128 TB) in order to avoid interference with applications
that require interrupt-served asynchronous request reception at
respectively low addresses.Note, this change does not switch remote DMA on. It only increases the
range of remote access to all memory (instead of just 4 GB) whenever
remote DMA was switched on by other means. The latter is achieved by
setting firewire-ohci's remote_dma parameter, or if the physical DMA
filter is opened through firewire-sbp2.Derived from patch "firewire: Enable physical DMA above 4GB" by
Peter Hurley from March 27, 2013.Signed-off-by: Stefan Richter
15 Nov, 2013
1 commit
-
Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: Wolfram Sang
Acked-by: Linus Walleij (personally at LCE13)
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Jul, 2013
1 commit
-
dbf2576e37 ("workqueue: make all workqueues non-reentrant") made
WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages.This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo
Signed-off-by: Stefan Richter
28 Sep, 2012
2 commits
-
Follow up on commit c285f6ff6787 "firewire: remove global lock around
address handlers, convert to RCU":- address_handler_lock no longer serializes the address handler, only
its function to serialize updates to the list of handlers remains.
Rename the lock to address_handler_list_lock.- Callers of fw_core_remove_address_handler() must be able to sleep.
Comment on this in the API documentation.- The counterpart fw_core_add_address_handler() is by nature something
which is used in process context. Replace spin_lock_bh() by
spin_lock() in fw_core_add_address_handler() and in
fw_core_remove_address_handler(), and document that process context
is now required for fw_core_add_address_handler().- Extend the documentation of fw_address_callback_t.
Signed-off-by: Stefan Richter
-
Upper-layer handlers for inbound requests were called with a spinlock
held by firewire-core. Calling into upper layers with a lower layer
lock held is generally a bad idea.What's more, since commit ea102d0ec475 "firewire: core: convert AR-req
handler lock from _irqsave to _bh", a caller of fw_send_request() i.e.
initiator of outbound request could no longer do that while having
interrupts disabled, if the local node was addressed by that request.In order to make all this more flexible, convert the management of
address ranges and handlers from a global lock around readers and
writers to RCU (and a remaining global lock for writers). As a minor
side effect, handling of inbound requests at different cards and of
local requests is now no longer serialized. (There is still per-card
serialization of remote requests since firewire-ohci uses a single DMA
tasklet for inbound request events.)In other words, address handlers are now called in an RCU read-side
critical section instead of from within a spin_lock_bh serialized
section.(Changelog rewritten by Stefan R.)
Signed-off-by: Peter Hurley
Signed-off-by: Stefan Richter
31 Jul, 2012
1 commit
-
Pull firewire updates from Stefan Richter:
- Small fixes and optimizations.
- A new sysfs attribute to tell local and remote nodes apart.
Useful to set special permissions/ ownership of local nodes'
/dev/fw*, to start daemons on them (for diagnostics, management,
AV targets, VersaPHY initiator or targets...), to pick up their
GUID to use it as GUID of an SBP2 target instance, and of course
for informational purposes.* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: core: document is_local sysfs attribute
firewire: core: add is_local sysfs device attribute
firewire: ohci: initialize multiChanMode bits after reset
firewire: core: fix multichannel IR with buffers larger than 2 GB
firewire: ohci: sanity-check MMIO resource
firewire: ohci: lazy bus time initialization
firewire: core: allocate the low memory region
firewire: core: make address handler length 64 bits
27 May, 2012
1 commit
-
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
Signed-off-by: Stefan Richter
25 May, 2012
1 commit
-
Pull IEEE 1394 (FireWire) subsystem updates from Stefan Richter:
- 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* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: sbp2: document the absence of alignment requirements
firewire: sbp2: remove superfluous blk_queue_max_segment_size() call
firewire: sbp2: use scsi_dma_(un)map
firewire: sbp2: give correct DMA device to scsi framework
firewire: core: fw_device_refresh(): clean up error handling
firewire: core: log config rom reading errors
firewire: core: log error in case of failed bus manager lock
firewire: move rcode_string() to core
firewire: core: improve reread_config_rom() interface
firewire: core: wait for inaccessible devices after bus reset
firewire: ohci: omit spinlock IRQ flags where possible
firewire: ohci: correct signedness of a local variable
firewire: core: fix DMA mapping direction
firewire: use module_pci_driver
10 May, 2012
1 commit
-
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: Chris Boot
Acked-by: Stefan Richter
Cc: Clemens Ladisch
Signed-off-by: Nicholas Bellinger
18 Apr, 2012
1 commit
-
There is nothing audio-specific about the rcode_string() helper, so move
it from snd-firewire-lib into firewire-core to allow other code to use it.Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter (fixed sound/firewire/cmp.c)
23 Feb, 2012
4 commits
-
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: 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->callbackThe 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: 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: 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, S800This 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: Stefan Richter
09 Oct, 2011
1 commit
-
Use kernel.h's convenience macros. Also omit a printk that should never
happen and won't matter much if it ever happened.Signed-off-by: Stefan Richter
11 May, 2011
3 commits
-
The struct sbp2_logical_unit.work items can all be executed in parallel
but are not reentrant. Furthermore, reconnect or re-login work must be
executed in a WQ_MEM_RECLAIM workqueue.Hence replace the old single-threaded firewire-sbp2 workqueue by a
concurrency-managed but non-reentrant workqueue with rescuer.
firewire-core already maintains one, hence use this one.In earlier versions of this change, I observed occasional failures of
parallel INQUIRY to an Initio INIC-2430 FireWire 800 to dual IDE bridge.
More testing indicates that parallel INQUIRY is not actually a problem,
but too quick successions of logout and login + INQUIRY, e.g. a quick
sequence of cable plugout and plugin, can result in failed INQUIRY.
This does not seem to be something that should or could be addressed by
serialization.Another dual-LU device to which I currently have access to, an
OXUF924DSB FireWire 800 to dual SATA bridge with firmware from MacPower,
has been successfully tested with this too.This change is beneficial to environments with two or more FireWire
storage devices, especially if they are located on the same bus.
Management tasks that should be performed as soon and as quickly as
possible, especially reconnect, are no longer held up by tasks on other
devices that may take a long time, especially login with INQUIRY and sd
or sr driver probe.Signed-off-by: Stefan Richter
-
firewire-core manages the following types of work items:
fw_card.br_work:
- resets the bus on a card and possibly sends a PHY packet before that
- does not sleep for long or not at all
- is scheduled via fw_schedule_bus_reset() by
- firewire-ohci's pci_probe method
- firewire-ohci's set_config_rom method, called by kernelspace
protocol drivers and userspace drivers which add/remove
Configuration ROM descriptors
- userspace drivers which use the bus reset ioctl
- itself if the last reset happened less than 2 seconds agofw_card.bm_work:
- performs bus management duties
- usually does not (but may in corner cases) sleep for long
- is scheduled via fw_schedule_bm_work() by
- firewire-ohci's self-ID-complete IRQ handler tasklet
- firewire-core's fw_device.work instances whenever the root node
device was (successfully or unsuccessfully) discovered,
refreshed, or rediscovered
- itself in case of resource allocation failures or in order to
obey the 125ms bus manager arbitration intervalfw_device.work:
- performs node probe, update, shutdown, revival, removal; including
kernel driver probe, update, shutdown and bus reset notification to
userspace drivers
- usually sleeps moderately long, in corner cases very long
- is scheduled by
- firewire-ohci's self-ID-complete IRQ handler tasklet via the
core's fw_node_event
- firewire-ohci's pci_remove method via core's fw_destroy_nodes/
fw_node_event
- itself during retries, e.g. while a node is powering upiso_resource.work:
- accesses registers at the Isochronous Resource Manager node
- usually does not (but may in corner cases) sleep for long
- is scheduled via schedule_iso_resource() by
- the owning userspace driver at addition and removal of the
resource
- firewire-core's fw_device.work instances after bus reset
- itself in case of resource allocation if necessary to obey the
1000ms reallocation period after bus resetfw_card.br_work instances should not, and instances of the others must
not, be executed in parallel by multiple CPUs -- but were not protected
against that. Hence allocate a non-reentrant workqueue for them.fw_device.work may be used in the memory reclaim path in case of SBP-2
device updates. Hence we need a workqueue with rescuer and cannot use
system_nrt_wq.Signed-off-by: Stefan Richter
Reviewed-by: Tejun Heo -
We do not need slab allocations anymore in order to satisfy
streaming DMA mapping constraints, thanks to commit da28947e7e36
"firewire: ohci: avoid separate DMA mapping for small AT payloads".(Besides, the slab-allocated buffers that firewire-core, firewire-sbp2,
and firedtv used to provide for 8-byte write and lock requests were
still not fully portable since they crossed cacheline boundaries or
shared a cacheline with unrelated CPU-accessed data. snd-firewire-lib
got this aspect right by using an extra kmalloc/ kfree just for the
8-byte transaction buffer.)This change replaces kmalloc'ed lock transaction scratch buffers in
firewire-core, firedtv, and snd-firewire-lib by local stack allocations.
Perhaps the most notable result of the change is simpler locking because
there is no need to serialize usages of preallocated per-device buffers
anymore. Also, allocations and deallocations are simpler.Signed-off-by: Stefan Richter
Acked-by: Clemens Ladisch
04 Jan, 2011
1 commit
-
Instead of starting the split transaction timeout timer when any request
is submitted, start it only when the destination's ACK_PENDING has been
received. This prevents us from using a timeout that is too short, and,
if the controller's AT queue is emptying very slowly, from cancelling
a packet that has not yet been sent.Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
14 Dec, 2010
1 commit
-
Change the header of PHY packets to be sent to include a pseudo
transaction code. This makes the header consistent with that of
received PHY packets, and allows at_context_queue_packet() and
log_ar_at_event() to see the packet type directly instead of having
to deduce it from the header length or even from the header contents.Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
12 Dec, 2010
1 commit
-
Add missing newlines.
Signed-off-by: Joe Perches
Signed-off-by: Stefan Richter
20 Aug, 2010
1 commit
-
Because we might be in interrupt context, replace del_timer_sync() with
del_timer(). If the timer is already running, we know that it will
clean up the transaction, so we do not need to do any further processing
in the normal transaction handler.Many thanks to Yong Zhang for diagnosing this.
Reported-by: Stefan Richter
Signed-off-by: Clemens Ladisch
Signed-off-by: Stefan Richter
23 Jul, 2010
3 commits
-
region->end is defined as an upper bound of the requested address range,
exclusive --- i.e. as an address outside of the range in which the
requested CSR is to be placed.Hence 0x0001,0000,0000,0000 is the biggest valid region->end, not
0x0000,ffff,ffff,fffc like the current check asserted.For simplicity, the fix drops the region->end & 3 test because there is
no actual problem with these bits set in region->end. The allocated
address range will be quadlet aligned and of a size of multiple quadlets
due to the checks for region->start & 3 and handler->length & 3 alone.Signed-off-by: Stefan Richter
-
Add an FW_CDEV_IOC_RECEIVE_PHY_PACKETS ioctl() and
FW_CDEV_EVENT_PHY_PACKET_RECEIVED poll()/read() event for /dev/fw*.
This can be used to get information from remote PHYs by remote access
PHY packets.This is also the 2nd half of the functionality (the receive part) to
support a userspace implementation of a VersaPHY transaction layer.Safety considerations:
- PHY packets are generally broadcasts, hence some kind of elevated
privileges should be required of a process to be able to listen in
on PHY packets. This implementation assumes that a process that is
allowed to open the /dev/fw* of a local node does have this
privilege.There was an inconclusive discussion about introducing POSIX
capabilities as a means to check for user privileges for these
kinds of operations.Other limitations:
- PHY packet reception may be switched on by ioctl() but cannot be
switched off again. It would be trivial to provide an off switch,
but this is not worth the code. The client should simply close()
the fd then, or just ignore further events.- For sake of simplicity of API and kernel-side implementation, no
filter per packet content is provided.Signed-off-by: Stefan Richter
-
core-transaction.c transmit_complete_callback() and close_transaction()
expect packet callback status to be an ACK or RCODE, and ACKs get
translated to RCODEs for transaction callbacks.An old comment on the packet callback API (been there from the initial
submission of the stack) and the dummy_driver implementation of
send_request/send_response deviated from this as they also included
-ERRNO in the range of status values.Let's narrow status values down to ACK and RCODE to prevent surprises.
RCODE_CANCELLED is chosen as the dummy_driver's RCODE as its meaning of
"transaction timed out" comes closest to what happens when a transaction
coincides with card removal.Signed-off-by: Stefan Richter
13 Jul, 2010
2 commits
-
Bus resets which are triggered
- by the kernel drivers after updates of the local nodes' config ROM,
- by userspace software via ioctl
shall be deferred until after >=2 seconds after the last bus reset.If multiple modifications of the local nodes' config ROM happen in a row,
only a single bus reset should happen after them.When the local node's link goes from inactive to active or vice versa,
and at the two occasions of bus resets mentioned above --- and if the
current gap count differs from 63 --- the bus reset should be preceded
by a PHY configuration packet that reaffirms the gap count. Otherwise a
bus manager would have to reset the bus again right after that.This is necessary to promote bus stability, e.g. leave grace periods for
allocations and reallocations of isochronous channels and bandwidth,
SBP-2 reconnections etc.; see IEEE 1394 clause 8.2.1.This change implements all of the above by moving bus reset initiation
into a delayed work (except for bus resets which are triggered by the
bus manager workqueue job and are performed there immediately). It
comes with a necessary addition to the card driver methods that allows
to get the current gap count from PHY registers.Signed-off-by: Stefan Richter
-
The present inline documentation of the fw_send_request() in-kernel API
refers to userland code that is not applicable to kernel drivers at all.Reported-by: Ben Gamari
While we are at fixing the whole documentation of fw_send_request(),
also improve the rest of firewire-core's kerneldoc comments:
- Add a bit of text concerning fw_run_transaction()'s call parameters.
- Append () to function names and tab-align parameter descriptions as
suggested by the example in Documentation/kernel-doc-nano-HOWTO.txt.
- Remove kerneldoc markers from comments on static functions.
- Remove outdated parameter descriptions at build_tree().Signed-off-by: Stefan Richter
21 Jun, 2010
2 commits
-
When a remote device does a LOCK_REQUEST, the core does not pass
the extended tcode to userspace. This patch makes it use the
juju-specific tcodes listed in firewire-constants.h for incoming
requests.Signed-off-by: Jay Fenlason
This matches how tcode in the API for outbound requests is treated.
Affects kernelspace and userspace drivers alike, but at the moment there
are no kernespace drivers that receive lock requests.Split out from a combo patch, slightly reordered, changelog reworded.
Signed-off-by: Stefan Richter
-
void (*fw_address_callback_t)(..., int speed, ...) is the speed that a
remote node chose to transmit a request to us. In case of split
transactions, firewire-core will transmit the response at that speed.Upper layer drivers on the other hand (firewire-net, -sbp2, firedtv, and
userspace drivers) cannot do anything useful with that speed datum,
except log it for debug purposes. But data that is merely potentially
(not even actually) used for debug purposes does not belong into the API.Signed-off-by: Stefan Richter
19 Jun, 2010
6 commits
-
which caused gcc 4.6 to warn about
variable 'destination' set but not used.Since the hardware ensures that we receive only response packets with
proper destination node ID (in a given bus generation), we have no use
for destination here in the core as well as in upper layers.(This is different with request packets. There we pass destination node
ID to upper layers because they may for example need to check whether
this was an unicast or broadcast request.)Reported-and-Tested-By: Justin P. Mattock
Signed-off-by: Stefan Richter -
Rather than "read a Control and Status Registers (CSR) Architecture
register" I prefer to say "read a Control and Status Register".Signed-off-by: Stefan Richter
-
All of these CSRs have the same read/ write/ aynthing-else handling,
except for CSR_PRIORITY_BUDGET which might not be implemented.The CSR_CYCLE_TIME read handler implementation accepted 4-byte-sized
block write requests before this change but this is just silly; the
register is only required to support quadlet read and write requests
like the other r/w CSR core and Serial-Bus-dependent registers.Signed-off-by: Stefan Richter
-
Push the maintenance of STATE_CLEAR/SET.abdicate down into the card
driver. This way, the read/write_csr_reg driver method works uniformly
across all CSR offsets.Signed-off-by: Stefan Richter
-
by feature variables in the fw_card struct. The hook appeared to be an
unnecessary abstraction in the card driver interface.Cleaner would be to pass those feature flags as arguments to
fw_card_initialize() or fw_card_add(), but the FairnessControl register
is in the SCLK domain and may therefore not be accessible while Link
Power Status is off, i.e. before the card->driver->enable call from
fw_card_add().Signed-off-by: Stefan Richter
-
Add a comment on which of the conflicting NODE_IDS specifications we
implement. Reduce a comment on rather irrelevant register bits that can
all be looked up in the spec (or from now on in the code history).
Directly include the required indirectly included bug.h.Signed-off-by: Stefan Richter
10 Jun, 2010
4 commits
-
Implement the abdicate bit, which is required for bus manager
capable nodes and tested by the Base 1394 Test Suite.Finally, something to do at a command reset! :-)
Signed-off-by: Clemens Ladisch
-
Implement the cmstr bit, which is required for cycle master capable
nodes and tested for by the Base 1394 Test Suite.This bit allows the bus master to disable cycle start packets; there are
bus master implementations that actually do this.Signed-off-by: Clemens Ladisch
-
Implement the MAIN_UTILITY register, which is utterly optional
but useful as a safe target for diagnostic read/write/broadcast
transactions.Signed-off-by: Clemens Ladisch
-
If supported by the OHCI controller, implement the PRIORITY_BUDGET
register, which is required for nodes that can use asynchronous
priority arbitration.To allow the core to determine what features the lowlevel device
supports, add a new card driver callback.Signed-off-by: Clemens Ladisch