linux-kernel - Re: [PATCH v2 1/1] staging: fwserial: Add TTY-over-Firewire serial driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1354064401.2703.13.camel@thor>
Date:	Tue, 27 Nov 2012 20:00:01 -0500
From:	Peter Hurley <peter@...leysoftware.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	linux1394-devel@...ts.sourceforge.net, linux-serial@...r.kernel.org
Subject: Re: [PATCH v2 1/1] staging: fwserial: Add TTY-over-Firewire serial
 driver

On Wed, 2012-11-28 at 00:58 +0100, Stefan Richter wrote:
> On Nov 27 Peter Hurley wrote:
> > > > Currently, firewire-net sets an arbitrary address handler length of
> > > > 4096. This works because the largest AR packet size the current
> > > > firewire-ohci driver handles is 4096 (value of MAX_ASYNC_PAYLOAD) +
> > > > header/trailer. Note that firewire-ohci does not limit card->max_receive
> > > > to this value.
> > > > 
> > > > So if the ohci driver changes to handle 8K+ AR packets and the hardware
> > > > supports it, these address handler windows will be too small.  
> > > 
> > > While the IEEE 1394:2008 link layer specification (section 6) provides for
> > > asynchronous packet payloads of up to 16384 bytes (table 6-4), the IEEE
> > > 1394 beta mode port specification (section 13) only allows up to 4096
> > > bytes (table 16-18).  And alpha mode is of course limited to 2048 bytes.
> > > 
> > > So, asynchronous packet payloads greater than 4096 bytes are out of scope
> > > of the current revision of IEEE 1394.  
> > 
> > You should look at this 1394ta.org video
> > http://www.youtube.com/watch?v=xVXNvXHNQTY of DAP Technologies S1600
> > OHCI controllers running S1600 cameras using beta cables.
> 
> I don't know the details of their implementation, but I suppose they conform
> with the 1394 beta mode port specification.  Which in turn means that their
> S1600 solution (and by extrapolation, their S3200 prototypes) comply with a
> maximum asynchronous packet payload of 4096 bytes.  Citing IEEE 1394-2008:
> 
> >>>
> 	Table 16-18———Maximum payload size for Beta data packets
>  Data rate | Maximum asynchronous payload size | Maximum isochronous payload
>            |              (bytes)              |           (bytes)
>  ----------+-----------------------------------+----------------------------
>     S100   |                 512               |             1024
>     S200   |                1024               |             2048
>     S400   |                2048               |             4096
>     S800   |                4096               |             8192
>     S1600  |                4096               |            16384
>     S3200  |                4096               |            32768
> <<<
> 
> (Alpha mode payload limits are the same as the S100...S400 subset of beta mode.
> In IEEE 1394b-2002, the table number is 16-3.)
> 
> You can of course define registers (or better termed: buffers) which are larger
> than what can be atomically read or written, or atomically compared-swapped;
> IOW which are larger than what can be accessed in a single transaction, if such
> registers or buffers are useful.  But if you particularly need a register which
> is just large enough to accommodate the largest possible inbound block write
> transaction which complies with IEEE 1394, and you don't know the peer's
> capability and the speeds of all intermediary cable hops, then
> fw_card.max_receive is the number that you need.  Or you ignore the cards actual
> capability and just allocate 4096 bytes.

Thanks for the clarification. I need to update
link_speed_to_max_payload() now. ;)

Plus I should just renew my IEEE membership so I can get the 1394-2008
spec without having to saw my arm off.

--
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/