linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux1394-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 6/6] staging/fwserial: Drop suggestion for helper fn integration
Date: Sat, 15 Dec 2012 13:34:10 +0100	[thread overview]
Message-ID: <20121215133410.0b6add5c@stein> (raw)
In-Reply-To: <1355551400-8204-7-git-send-email-peter@hurleysoftware.com>

On Dec 15 Peter Hurley wrote:
> The firewire core does not require or want the suggested helper fns;
> drop suggestion from TODO file.

It's not about the core, but about what the highlevel drivers need.
(I.e. protocol drivers and some higherlevel parts of the core, e.g.
the userspace driver interface.)

If it is something which two or more drivers use, it goes into the core.
(Or into a library, as Clemens did with snd-firewire-lib.)  If it is
something which needs assistance by the lowlevel driver, it goes into the
core or passes through the core, regardless whether one or more protocol
drivers need it.  (Example:  Physical DMA filtering for the SBP-2
initiator driver.)  If it is something very complicated and 1394
architecture specific, but still only needed by one highlevel driver, I
for one am more comfortable with leaving this in the respective driver
rather than moving this into the core.

The packet payload calculation is a 1394 architecture arcanum and is needed
in on form or another in more than one driver (firewire-net, -sbp2, and
now fwserial).  But as discussed, what they precisely need in the end
differs to a degree that leaves nothing substantial to share.

[That's too many words about a two- or three-line piece of code; but on the
on the other hand it is a generally relevant consideration whenever new
functionality is to be added somewhere in the driver stack.]
-- 
Stefan Richter
-=====-===-- ==-- -====
http://arcgraph.de/sr/

  reply	other threads:[~2012-12-15 12:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-15  6:03 [PATCH v2 0/5] staging/fwserial: Address reviewer comments Peter Hurley
2012-12-15  6:03 ` [PATCH v2 1/6] staging/fwserial: Refine Kconfig help text Peter Hurley
2012-12-15  6:03 ` [PATCH v2 2/6] staging/fwserial: Remove bandwidth limit logic Peter Hurley
2012-12-15  6:03 ` [PATCH v2 3/6] staging/fwserial: Limit tx/rx to 1394-2008 spec maximum Peter Hurley
2012-12-15  6:03 ` [PATCH v2 4/6] staging/fwserial: Update TODO file per reviewer comments Peter Hurley
2012-12-15  6:03 ` [PATCH v2 5/6] staging/fwserial: Assume firmware is OHCI-complaint Peter Hurley
2012-12-15  6:03 ` [PATCH v2 6/6] staging/fwserial: Drop suggestion for helper fn integration Peter Hurley
2012-12-15 12:34   ` Stefan Richter [this message]
2012-12-15 16:09     ` Stefan Richter
2013-01-07 23:22 ` [PATCH v2 0/5] staging/fwserial: Address reviewer comments Greg Kroah-Hartman
2013-01-08 14:59   ` Peter Hurley
2013-01-29  1:57   ` [PATCH v3 0/6] " Peter Hurley
2013-01-29  1:57     ` [PATCH v3 1/6] staging/fwserial: Remove bandwidth limit logic Peter Hurley
2013-01-29  1:57     ` [PATCH v3 2/6] staging/fwserial: Refer to fw_device as "node" Peter Hurley
2013-01-29  1:57     ` [PATCH v3 3/6] staging/fwserial: Simplify max payload calculation Peter Hurley
2013-01-29  1:57     ` [PATCH v3 4/6] staging/fwserial: Fold constant MAX_ASYNC_PAYLOAD Peter Hurley
2013-01-29  1:57     ` [PATCH v3 5/6] staging/fwserial: Assume firmware is OHCI-complaint Peter Hurley
2013-01-29  1:57     ` [PATCH v3 6/6] staging/fwserial: Drop suggestion for helper fn integration Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121215133410.0b6add5c@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=peter@hurleysoftware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).