All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Clemens Ladisch <clemens@ladisch.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org,
	linux1394-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging/fwserial: use correct vendor/version IDs
Date: Tue, 03 Feb 2015 09:00:14 -0500	[thread overview]
Message-ID: <54D0D46E.2040907@hurleysoftware.com> (raw)
In-Reply-To: <20150203094425.2def7f79@kant>

On 02/03/2015 03:44 AM, Stefan Richter wrote:
> On Feb 02 Peter Hurley wrote:
>> On 01/28/2015 03:07 PM, Clemens Ladisch wrote:
>>> The driver was using the vendor ID 0xd00d1e from the FireWire core.
>>> However, this ID was not registered, and invalid.
>>>
>>> Instead, use the vendor/version IDs that now are officially assigned to
>>> firewire-serial:
>>> https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments
>>
>> That's great that we have official OUIs now, but I have to NACK this
>> patch as is.
>>
>> The problem is a host with the old OUIs will not recognize a remote
>> unit with the new OUIs, and vice versa.
>>
>> Even though the new ids could be added to the unit driver's id_table,
>> (which would let hosts with the new OUI connect to either OUI remote),
>> it wouldn't let 3.19- hosts connect to 3.20+ hosts.
> 
> Actually there are no 3.19- hosts that speak fwserial; there are only
> staging hosts that do so.  So, with this patch added, certain staging
> hosts would become unable to talk with certain other staging hosts (and
> with future Linux hosts, once fwserial gets merged upstream).

The breakage seems gratuitous especially considering the existing OUI
has been in use for a decade.

> Both fwserial-the-implementation and fwserial-the-protocol are your own,
> and as yet unmerged.

I've been waiting for you to work through the patch backlog from Feb and
Mar of last year before sending you more patches to merge fwserial.

>  (In addition, there does not yet exist a second
> implementation, AFAIK.)  So I'd say there is still opportunity to improve
> the protocol even in incompatible ways if justified.  Switching to
> valid identifiers may very well be such a justifiable change.

I would appreciate you sharing any suggestions for improving the protocol.

While I concede the protocol is not perfect, I'm struggling to see how
changing the OUI improves it.

Regards,
Peter Hurley



  reply	other threads:[~2015-02-03 14:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <54C940E0.5090906@ladisch.de>
2015-01-28 20:07 ` [PATCH] staging/fwserial: use correct vendor/version IDs Clemens Ladisch
2015-01-29  9:44   ` Stefan Richter
2015-02-02 22:08   ` Peter Hurley
2015-02-03  8:44     ` Stefan Richter
2015-02-03 14:00       ` Peter Hurley [this message]
2015-02-03 21:22         ` Stefan Richter
2015-02-07  9:10   ` Greg Kroah-Hartman

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=54D0D46E.2040907@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=clemens@ladisch.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=stefanr@s5r6.in-berlin.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.