summaryrefslogtreecommitdiffstats
path: root/drivers/firewire
Commit message (Collapse)AuthorAgeFilesLines
* firewire: ohci: work around VIA and NEC PHY packet reception bugStefan Richter2010-08-291-1/+9
| | | | | | | | | | | | | | | | | | | | | VIA VT6306, VIA VT6308, and NEC OrangeLink controllers do not write packet event codes for received PHY packets (or perhaps write evt_no_status, hard to tell). Work around it by overwriting the packet's ACK by ack_complete, so that upper layers that listen to PHY packet reception get to see these packets. (Also tested: TI TSB82AA2, TI TSB43AB22/A, TI XIO2213A, Agere FW643, JMicron JMB381 --- these do not exhibit this bug.) Clemens proposed a quirks flag for that, IOW whitelist known misbehaving controllers for this workaround. Though to me it seems harmless enough to enable for all controllers. The log_ar_at_event() debug log will continue to show the original status from the DMA unit. Reported-by: Clemens Ladisch <clemens@ladisch.de> (VT6308) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: core: do not use del_timer_sync() in interrupt contextClemens Ladisch2010-08-191-3/+10
| | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de> Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: net: fix unicast reception RCODE in failure pathsStefan Richter2010-08-191-13/+15
| | | | | | | | | | | | | | | | The incoming request hander fwnet_receive_packet() expects subsequent datagram handling code to return non-zero on errors. However, almost none of the failure paths did so. Fix them all. (This error reporting is used to send and RCODE_CONFLICT_ERROR to the sender node in such failure cases. Two modes of failure exist: Out of memory, or firewire-net is unaware of any peer node to which a fragment or an ARP packet belongs. However, it is unclear whether a sender can actually make use of such information. A Linux peer apparently can't. Maybe it should all be simplified to void functions.) Reported-by: Julia Lawall <julia@diku.dk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: sbp2: fix stall with "Unsolicited response"Stefan Richter2010-08-191-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix I/O stalls with some 4-bay RAID enclosures which are based on OXUF936QSE: - Onnto dataTale RSM4QO, old firmware (not anymore with current firmware), - inXtron Hydra Super-S LCM, old as well as current firmware when used in RAID-5 mode, perhaps also in other RAID modes. The stalls happen during heavy or moderate disk traffic in periods that are a multiple of 5 minutes, roughly twice per hour. They are caused by the target responding too late to an ORB_Pointer register write: The target responds after Split_Timeout, hence firewire-core cancels the transaction, and firewire-sbp2 fails the SCSI request. The SCSI core retries the request, that fails again (and again), hence SCSI core calls firewire-sbp2's abort handler (and even the Management_Agent register write in the abort handler has the transaction timeout problem). During all that, the process which issued the I/O is stalled in I/O wait state. Meanwhile, the target actually acts on the first failed SCSI request: It responds to the ORB_Pointer write later (seen in the kernel log as "firewire_core: Unsolicited response") and also finishes the SCSI request with proper status (seen in the kernel log as "firewire_sbp2: status write for unknown orb"). So let's just ignore RCODE_CANCELLED in the transaction callback and wait for the target to complete the ORB nevertheless. This requires a small modification is sbp2_cancel_orbs(); it now needs to call orb->callback() regardless whether fw_cancel_transaction() found the transaction unfinished or finished. A different solution is to increase Split_Timeout on the local node. (Tested: 2000ms timeout; maybe 1000ms or something like that works too. 200ms is insufficient. Standard is 100ms.) However, I rather not do this because any software on any node could change the Split_Timeout to something unsuitable. Or such a large Split_Timeout may be undesirable for other purposes. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send errorStefan Richter2010-08-191-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an ORB was canceled (Command ORB i.e. SCSI request timed out, or Management ORB timed out), or there was a send error in the initial transaction, we missed to drop one of the ORB's references and thus leaked memory. Background: In total, we hold 3 references to each Operation Request Block: - 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb() respectively, - 1 for the duration of the write transaction to the ORB_Pointer or Management_Agent register of the target, - 1 for as long as the ORB stays within the lu->orb_list, until the ORB is unlinked from the list and the orb->callback was executed. The latter one of these 3 references is finished - normally by sbp2_status_write() when the target wrote status for a pending ORB, - or by sbp2_cancel_orbs() in case of an ORB time-out, - or by complete_transaction() in case of a send error. Of them, the latter two lacked the kref_put. Add the missing kref_put()s. Add comments to the gets and puts of references for transaction callbacks and ORB callbacks so that it is easier to see what is supposed to happen. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
*-. Merge firewire branches to be released post v2.6.35Stefan Richter2010-08-0216-418/+2333
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/firewire/core-card.c drivers/firewire/core-cdev.c and forgotten #include <linux/time.h> in drivers/firewire/ohci.c Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: add forgotten dummy driver methods, remove unused onesStefan Richter2010-08-021-26/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is an at least theoretic race condition in which .start_iso etc. could still be called between when the dummy driver is bound to the card and when the children devices are being shut down. Add dummy_start_iso and friends. On the other hand, .enable, .set_config_rom, .read_csr, write_csr do not need to be implemented by the dummy driver, as commented. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: add isochronous multichannel receptionStefan Richter2010-07-294-97/+346
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the DMA context programming and userspace ABI for multichannel reception, i.e. for listening on multiple channel numbers by means of a single DMA context. The use case is reception of more streams than there are IR DMA units offered by the link layer. This is already implemented by the older ohci1394 + ieee1394 + raw1394 stack. And as discussed recently on linux1394-devel, this feature is occasionally used in practice. The big drawbacks of this mode are that buffer layout and interrupt generation necessarily differ from single-channel reception: Headers and trailers are not stripped from packets, packets are not aligned with buffer chunks, interrupts are per buffer chunk, not per packet. These drawbacks also cause a rather hefty code footprint to support this rarely used OHCI-1394 feature. (367 lines added, among them 94 lines of added userspace ABI documentation.) This implementation enforces that a multichannel reception context may only listen to channels to which no single-channel context on the same link layer is presently listening to. OHCI-1394 would allow to overlay single-channel contexts by the multi-channel context, but this would be a departure from the present first-come-first-served policy of IR context creation. The implementation is heavily based on an earlier one by Jay Fenlason. Thanks Jay. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: small clarifications in core-cdevStefan Richter2010-07-291-6/+6
| | | | | | | | | | | | | | | | | | | | | Make a note on the seemingly unused linux/sched.h. Rename an irritatingly named variable. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: remove unused codeStefan Richter2010-07-291-6/+2
| | | | | | | | | | | | | | | | | | ioctl_create_iso_context enforces ctx->header_size >= 4. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: ohci: release channel in error pathStefan Richter2010-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | firewire-ohci keeps book of which isochronous channels are occupied by IR DMA contexts, so that there cannot be more than one context listening to a certain channel. If IR context creation failed due to an out-of-memory condition, this bookkeeping leaked a channel. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: ohci: use memory barriers to order descriptor updatesStefan Richter2010-07-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | When we append to a DMA program, we need to ensure that the order in which initialization of the new descriptors and update of the branch_address of the old tail descriptor, as seen by the PCI device, happen as intended. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: improve FW_CDEV_IOC_ALLOCATEStefan Richter2010-07-231-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In both the ieee1394 stack and the firewire stack, the core treats kernelspace drivers better than userspace drivers when it comes to CSR address range allocation: The former may request a register to be placed automatically at a free spot anywhere inside a specified address range. The latter may only request a register at a fixed offset. Hence, userspace drivers which do not require a fixed offset potentially need to implement a retry loop with incremented offset in each retry until the kernel does not fail allocation with EBUSY. This awkward procedure is not fundamentally necessary as the core already provides a superior allocation API to kernelspace drivers. Therefore change the ioctl() ABI by addition of a region_end member in the existing struct fw_cdev_allocate. Userspace and kernelspace APIs work the same way now. There is a small cost to pay by clients though: If client source code is required to compile with older kernel headers too, then any use of the new member fw_cdev_allocate.region_end needs to be enclosed by #ifdef/#endif directives. However, any client program that seriously wants to use address range allocations will require a kernel of cdev ABI version >= 4 at runtime and a linux/firewire-cdev.h header of >= 4 anyway. This is because v4 brings FW_CDEV_EVENT_REQUEST2. The only client program in which build-time compatibility with struct fw_cdev_allocate as found in older kernel headers makes sense is libraw1394. (libraw1394 uses the older broken FW_CDEV_EVENT_REQUEST to implement a makeshift, incorrect transaction responder that does at least work somewhat in many simple scenarios, relying on guesswork by libraw1394 and by libraw1394 based applications. Plus, address range allocation and transaction responder is only one of many features that libraw1394 needs to provide, and these other features need to work with kernel and kernel-headers as old as possible. Any new linux/firewire-cdev.h based client that implements a transaction responder should never attempt to do it like libraw1394; instead it should make a header and kernel of v4 or later a hard requirement.) While we are at it, update the struct fw_cdev_allocate documentation to better reflect the recent fw_cdev_event_request2 ABI addition. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: fix upper bound of possible CSR allocationsStefan Richter2010-07-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: add PHY pingingStefan Richter2010-07-233-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extends the FW_CDEV_IOC_SEND_PHY_PACKET ioctl() for /dev/fw* to be useful for ping time measurements. One application for it would be gap count optimization in userspace that is based on ping times rather than hop count. (The latter is implemented in firewire-core itself but is not applicable to beta PHYs that act as repeater.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: add PHY packet receptionStefan Richter2010-07-235-7/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: add PHY packet transmissionStefan Richter2010-07-231-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an FW_CDEV_IOC_SEND_PHY_PACKET ioctl() for /dev/fw* which can be used to implement bus management related functionality in userspace. This is also half of the functionality (the transmit part) that is needed to support a userspace implementation of a VersaPHY transaction layer. Safety considerations: - PHY packets are generally broadcasts and may have interesting effects on PHYs and the bus, e.g. make asynchronous arbitration impossible due to too low gap count. Hence some kind of elevated privileges should be required of a process to be able to send 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. - The kernel does not check integrity of the supplied packet data. That would be far too much code, considering the many kinds of PHY packets. A process which got the privilege to send these packets is trusted to do it correctly. Just like with the other "send packet" ioctls, a non-blocking API is chosen; i.e. the ioctl may return even before AT DMA started. After transmission, an event for poll()/read() is enqueued. Most users are going to need a blocking API, but a blocking userspace wrapper is easy to implement, and the second of the two existing libraw1394 calls raw1394_phy_packet_write() and raw1394_start_phy_packet_write() can be better supported that way. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: use C99 initializer in array of ioctl handlersStefan Richter2010-07-231-21/+21
| | | | | | | | | | | | | | | | | | to make the correspondence of ioctl numbers and handlers more obvious. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: normalize status values in packet callbacksStefan Richter2010-07-232-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: core: integrate software-forced bus resets with bus managementStefan Richter2010-07-135-36/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: fix fw_cdev_event_bus_reset emission after local config ROM ↵Stefan Richter2010-07-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changes When a descriptor was added or removed to the local node's config ROM, userspace clients which had a local node's /dev/fw* open did not receive any fw_cdev_event_bus_reset for poll()/read() consumption. The cause was that the core-device.c facility which re-reads the config ROM of the bus reset initiator node missed to call the fw_device update function. The fw_units are destroyed and newly added, but their parent stays and needs to be updated. Reported-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: ensure some userspace API constants match corresponding ↵Stefan Richter2010-07-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kernel API constants The FW_ISO_ constants of the in-kernel API of firewire-core and FW_CDEV_ISO_ constants of the userspace API of firewire-core have nothing to do with each other --- except that the core-cdev.c implementation relies on them having the same values. Hence put some compile-time assertions into core-cdev.c. It's lame but I prefer it over including the userspace API header into the kernelspace API header and defining kernelspace API constants from userspace API constants. Nor do I want to expose the kernelspace constants in one of the two firewire headers that are exported to userland since this only concerns the core-cdev.c implementation. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: fix fw_send_request kerneldoc commentStefan Richter2010-07-134-55/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bgamari.foss@gmail.com> 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: check write quadlet request length to avoid buffer overflowClemens Ladisch2010-07-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check that the data length of a write quadlet request actually is large enough for a quadlet. Otherwise, fw_fill_request could access the four bytes after the end of the outbound_transaction_event structure. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Modification of Clemens' change: Consolidate the check into init_request() which is used by the affected ioctl_send_request() and ioctl_send_broadcast_request() and the unaffected ioctl_send_stream_packet(), to save a few lines of code. Note, since struct outbound_transaction_event *e is slab-allocated, such an out-of-bounds access won't hit unallocated memory but may result in a (virtually impossible to exploit) information disclosure. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: fix fw_cdev_event_bus_reset.bm_node_idStefan Richter2010-07-083-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | Fix an obscure ABI feature that is a bit of a hassle to implement. However, somebody put it into the ABI, so let's fill in a sensible value there. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: no need to track irq flags in bm_workStefan Richter2010-07-081-8/+7
| | | | | | | | | | | | | | | | | | This is a workqueue job and always entered with IRQs enabled. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: fix ABI for FCP and address range mapping, add ↵Stefan Richter2010-06-201-9/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fw_cdev_event_request2 The problem: A target-like userspace driver, e.g. AV/C target or SBP-2/3 target, needs to be able to act as responder and requester. In the latter role, it needs to send requests to nods from which it received requests. This is currently impossible because fw_cdev_event_request lacks information about sender node ID. Reported-by: Jay Fenlason <fenlason@redhat.com> Libffado + libraw1394 + firewire-core is currently unable to drive two or more audio devices on the same bus. Reported-by: Arnold Krille <arnold@arnoldarts.de> This is because libffado requires destination node ID of FCP requests and sender node ID of FCP responses to match. It even prohibits libffado from working with a bus on which libraw1394 opens a /dev/fw* as default ioctl device that does not correspond with the audio device. This is because libraw1394 does not receive the sender node ID from the kernel. Moreover, fw_cdev_event_request makes it impossible to tell unicast and broadcast write requests apart. The fix: Add a replacement of struct fw_cdev_event_request request, boringly called struct fw_cdev_event_request2. The new event will be sent to a userspace client instead of the old one if the client claims compatibility with <linux/firewire-cdev.h> ABI version 4 or later. libraw1394 needs to be extended to make use of the new event, in order to properly support libffado and other FCP or address range mapping users who require correct sender node IDs. Further notes: While we are at it, change back the range of possible values of fw_cdev_event_request.tcode to 0x0...0xb like in ABI version <= 3. The preceding change "firewire: expose extended tcode of incoming lock requests to (userspace) drivers" expanded it to 0x0...0x17 which could catch sloppily coded clients by surprise. The extended range of codes is only used in the new fw_cdev_event_request2.tcode. Jay and I also suggested an alternative approach to fix the ABI for incoming requests: Add an FW_CDEV_IOC_GET_REQUEST_INFO ioctl which can be called after reception of an fw_cdev_event_request, before issuing of the closing FW_CDEV_IOC_SEND_RESPONSE ioctl. The new ioctl would reveal the vital information about a request that fw_cdev_event_request lacks. Jay showed an implementation of this approach. The former event approach adds 27 LOC of rather trivial code to core-cdev.c, the ioctl approach 34 LOC, some of which is nontrivial. The ioctl approach would certainly also add more LOC to userspace programs which require the expanded information on inbound requests. This approach is probably only on the lighter-weight side in case of clients that want to be compatible with kernels that lack the new capability, like libraw1394. However, the code to be added to such libraw1394-like clients in case of the event approach is a straight- forward additional switch () case in its event handler. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: expose extended tcode of incoming lock requests to (userspace) driversJay Fenlason2010-06-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <fenlason@redhat.com> 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: freeze FW_CDEV_VERSION due to libraw1394 bugStefan Richter2010-06-201-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libraw1394 v2.0.0...v2.0.5 takes FW_CDEV_VERSION from an externally installed header file and uses it to declare its own implementation level in FW_CDEV_IOC_GET_INFO. This is wrong; it should set the real version for which it was actually written. If we add features to the kernel ABI that require the kernel to check a client's implementation level, we can not trust the client version if it was set from FW_CDEV_VERSION. Hence freeze FW_CDEV_VERSION at the current value (no damage has been done yet), clearly document FW_CDEV_VERSION as a dummy version and what clients are expected to do with fw_cdev_get_info.version, and use a new defined constant (which is not placed into the exported header file) as kernel implementation level. Note, in order to check in client program source code which features are present in an externally installed linux/firewire-cdev.h, use preprocessor directives like #ifdef FW_CDEV_IOC_ALLOCATE_ISO_RESOURCE or #ifdef FW_CDEV_EVENT_ISO_RESOURCE_ALLOCATED instead of a check of FW_CDEV_VERSION. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: count references of cards during inbound transactionsStefan Richter2010-06-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a request comes in to an address range managed by a userspace driver i.e. <linux/firewire-cdev.h> client, the card instance of request and response may differ from the card instance of the client device. Therefore we need to take a reference of the card until the response was sent. I thought about putting the reference counting into core-transaction.c, but the various high-level drivers besides cdev clients (firewire-net, firewire-sbp2, firedtv) use the card pointer in their fw_address_handler address_callback method only to look up devices of which they already hold the necessary references. So this seems to be a specific firewire-cdev issue which is better addressed locally. We do not need the reference - in case of FCP_REQUEST or FCP_RESPONSE requests because then the firewire-core will send the split transaction response for us already in the context of the request handler, - if it is the same card as the client device's because we hold a card reference indirectly via teh client->device reference. To keep things simple, we take the reference nevertheless. Jay Fenlason wrote: > there's no way for the core to tell cdev "this card is gone, > kill any inbound transactions on it", while cdev holds the transaction > open until userspace issues a SEND_RESPONSE ioctl, which may be a very, > very long time. But when it does, it calls fw_send_response(), which > will dereference the card... > > So how unhappy are we about userspace potentially holding a fw_card > open forever? While termination of inbound transcations at card removal could be implemented, it is IMO not worth the effort. Currently, the effect of holding a reference of a card that has been removed is to block the process that called the pci_remove of the card. This is - either a user process ran by root. Root can find and kill processes that have /dev/fw* open, if desired. - a kernel thread (which one?) in case of hot removal of a PCCard or ExpressCard. The latter case could be a problem indeed. firewire-core's card shutdown and card release should probably be improved not to block in shutdown, just to defer freeing of memory until release. This is not a new problem though; the same already always happens with the client->device->card without the need of inbound transactions or other special conditions involved, other than the client not closing the file. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: cdev: fix responses to nodes at different cardJay Fenlason2010-06-201-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My box has two firewire cards in it: card0 and card1. My application opens /dev/fw0 (card 0) and allocates an address space. The core makes the address space available on both cards. Along comes the remote device, which sends a READ_QUADLET_REQUEST to card1. The request gets passed up to my application, which calls ioctl_send_response(). ioctl_send_response() then calls fw_send_response() with card0, because that's the card it's bound to. Card0's driver drops the response, because it isn't part of a transaction that it has outstanding. So in core-cdev: handle_request(), we need to stash the card of the inbound request in the struct inbound_transaction_resource and use that card to send the response to. The hard part will be refcounting the card correctly so it can't get deallocated while we hold a pointer to it. Here's a trivial patch, which does not do the card refcounting, but at least demonstrates what the problem is. Note that we can't depend on the fact that the core-cdev:client structure holds a card open, because in this case the card it holds open is not the card the request came in on. ..and there's no way for the core to tell cdev "this card is gone, kill any inbound transactions on it", while cdev holds the transaction open until userspace issues a SEND_RESPONSE ioctl, which may be a very, very long time. But when it does, it calls fw_send_response(), which will dereference the card... So how unhappy are we about userspace potentially holding a fw_card open forever? Signed-off-by: Jay Fenlason <fenlason@redhat.com> Reference counting to be addressed in a separate change. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
| | * firewire: cdev: fix race in iso context creationClemens Ladisch2010-06-201-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | Protect the client's iso context pointer against a race that can happen when more than one creation call is executed at the same time. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: remove an unused function argumentStefan Richter2010-06-204-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: core: remove an unnecessary zero initializationStefan Richter2010-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | All of the fields of the iso_interrupt_event instance are overwritten right after it was allocated. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: core: remove unused variableStefan Richter2010-06-191-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <justinmattock@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: rename CSR access driver methodsStefan Richter2010-06-194-13/+11
| | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: core: combine some repeated codeStefan Richter2010-06-191-69/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: normalize STATE_CLEAR/SET CSR access interfaceStefan Richter2010-06-194-38/+29
| | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: replace get_features card driver hookStefan Richter2010-06-194-21/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: drop sizeof expressions from some request size argumentsStefan Richter2010-06-192-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of fw_card_bm_work()'s lock request, the present sizeof expression is going to be wrong if somebody changes the fw_card's DMA scratch buffer's size in the future. In case of quadlet write requests, sizeof(u32) is just silly; it's 4. In case of SBP-2 ORB pointer write requests, 8 is arguably quicker to understand as the correct and only possible value than sizeof(some_datum). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| | * firewire: 'add CSR_... support' addendumStefan Richter2010-06-192-21/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
| | * firewire: core: always enable cycle master packetsClemens Ladisch2010-06-101-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | As part of the bus manager responsibilities, make sure that the cycle master sends cycle start packets. This is needed when the old bus manager disabled the cycle master's cmstr bit and there are iso-capable nodes on the new bus. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
| | * firewire: allocate broadcast channel in hardwareClemens Ladisch2010-06-104-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | On OHCI 1.1 controllers, let the hardware allocate the broadcast channel automatically. This removes a theoretical race condition directly after a bus reset where it could be possible to read the channel allocation register with channel 31 still being unallocated. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
| | * firewire: core: add CSR abdicate supportClemens Ladisch2010-06-104-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <clemens@ladisch.de>
| | * firewire: add CSR cmstr supportClemens Ladisch2010-06-104-2/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <clemens@ladisch.de>
| | * firewire: core: add CSR MAINT_UTILITY supportClemens Ladisch2010-06-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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 <clemens@ladisch.de>
| | * firewire: add CSR PRIORITY_BUDGET supportClemens Ladisch2010-06-103-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <clemens@ladisch.de>
| | * firewire: add CSR BUSY_TIMEOUT supportClemens Ladisch2010-06-102-4/+24
| | | | | | | | | | | | | | | | | | | | | Implement the BUSY_TIMEOUT register, which is required for nodes that support retries. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
| | * firewire: add CSR BUS_TIME supportClemens Ladisch2010-06-102-62/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | Implement the BUS_TIME register, which is required for cycle master capable nodes and tested for by the Base 1393 Test Suite. Even when there is not yet bus master initialization support, this register allows us to work together with other bus masters. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
| | * firewire: add CSR CYCLE_TIME write supportClemens Ladisch2010-06-102-0/+10
| | | | | | | | | | | | | | | | | | | | | The specification requires that CYCLE_TIME is writable so that it can be initialized, so we better implement it. Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
OpenPOWER on IntegriCloud