Message-Id: <5C167A1D-2203-4F1C-B538-E99DD87E7E42@bootc.net>
Date:	Mon, 6 Feb 2012 22:28:57 +0000
From:	Chris Boot <bootc@...tc.net>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Clemens Ladisch <clemens@...isch.de>, target-devel@...r.kernel.org,
	linux1394-devel@...ts.sourceforge.net,
	Boaz Harrosh <bharrosh@...asas.com>,
	Andy Grover <agrover@...hat.com>, linux-scsi@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: FireWire/SBP2 Target mode

On 6 Feb 2012, at 20:26, Stefan Richter wrote:

> On Feb 06 Chris Boot wrote:
>> On 06/02/2012 14:43, Clemens Ladisch wrote:
>>> Chris Boot wrote:
>>>> You can pull the code from:
>>>> git://github.com/bootc/Linux-SBP-2-Target.git
>>> 
>>> The TODO file says:
>>>> * Update Juju so we can get the speed in the fw_address_handler callback
>>> 
>>> What is the speed needed for?
>> 
>> "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."
>> 
>> (T10/1155D Revision 4 page 53/54)
> 
> I guess it is not too hard to add this to the AR-req handler.  On the
> other hand, I see little reason to follow the SBP-2 spec to the letter
> here.  The target driver could just use the maximum speed that the core
> figured out.  On the other hand, this requires of course
>  - the target to wait for core to finish scanning an initiator,
>  - the core to offer an API to look up an fw_device by a
>    card--generation--nodeID tuple.
> 
> The intention of the spec is IMO clearly to enable target implementations
> that do not need to implement topology scanning.  I have a hard time to
> think of a valid scenario where an initiator needs to be able to steer a
> target towards a lower wire speed than what the participating links and
> PHYs actually support.

The only thing stopping me from getting the speed is the fact that struct fw_request is opaque. The value is easily available from request->response.speed and I kind of do that already in a very hackish way. I've sent a separate patch which adds a function that can be used to access that one value.

Waiting until the bus scan is complete isn't actually that great as I see the first LOGIN requests often before the fw_node is seen at all. I'd have to turn away the requester and hope they try again. I'm fairly sure my little tweak in my patch is a simple enough solution.

>>> SBP-2 says:
>>> | The target shall issue data transfer requests with a speed equal to
>>> | that specified by the spd field in the ORB.
>>> 
>>> SBP-3 says:
>>> | The target shall issue data transfer requests with a speed equal to
>>> | that specified by the controlling spd field, whether in the ORB or in
>>> | a node selector in an associated page table.
> 
> Clemens, the speed used in data transfers can be different from the speed
> to be used to read the initiator's Config ROM/ fetch ORBs/ write status,
> because data buffers and page tables can reside on a third node.  (In
> practice they reside always on the initiator node, but per spec they
> don't have to.)
> 
> Again, IMO the target driver could ignore this other speed too and just
> use the speed which firewire-core figured out.  But on the other hand,
> this would require an fw_device lookup, given card--generation--nodeID; so
> using the speed code given in the ORB is much simpler.
> 
> Side note:  Like with the speed, the max_payload given in the ORB may be
> different from that in the initiator's bus information block, simply
> because the data buffers and page tables may reside on a third node with a
> different packet payload limit.  Again, just using the max_payload given
> in the ORB makes for the easiest implementation (and follows the spec to
> the letter).

Hmm yes so far I've ignored the fact that the data and page tables can be on a different node. I should add that to the TODO fairly low down :-)

>>>> Please note that you can't then disable a unit until all the targets
>>>> are logged-out. For Linux this usually means 'rmmod firewire_sbp2'.
>>> 
>>> That driver should not, by default, log into targets on its own node.
>> 
>> It still tries to and never appears to give up, so this needs 
>> blacklisting on the target system until firewire_sbp2 is changed. It's 
>> harmless other than filling up the kernel log with error messages.
>> 
>> What I meant, however, is if you connect to the target from a separate 
>> Linux system you will be unable to disable the unit on the target system 
>> until the _initiator_ logs out. You can do this on the initiator by 
>> unloading the module, which sends a logout request to the target.
> 
> Another way to log out is
> # echo "fw4.0" > /sys/bus/firewire/drivers/*sbp2/unbind
> 
> (I will post a patch soon which renames this directory from sbp2 to
> firewire_sbp2, as a side effect of a logging related change.)

Good to know, thanks!

HTH,
Chris

-- 
Chris Boot
bootc@...tc.net

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists