LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] staging/fwserial: use correct vendor/version IDs
       [not found] <54C940E0.5090906@ladisch.de>
@ 2015-01-28 20:07 ` Clemens Ladisch
  2015-01-29  9:44   ` Stefan Richter
                     ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Clemens Ladisch @ 2015-01-28 20:07 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Peter Hurley
  Cc: Stefan Richter, devel, linux1394-devel, linux-kernel

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

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
---
 drivers/staging/fwserial/TODO       |    5 ++---
 drivers/staging/fwserial/fwserial.c |    4 ++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/fwserial/TODO b/drivers/staging/fwserial/TODO
index 382a795..c3d1d3a 100644
--- a/drivers/staging/fwserial/TODO
+++ b/drivers/staging/fwserial/TODO
@@ -9,6 +9,5 @@ TODOs prior to this driver moving out of staging
    GUID-to-port matching/whitelist/blacklist.

 -- Issues with firewire stack --
-1. This driver uses the same unregistered vendor id that the firewire core does
-     (0xd00d1e). Perhaps this could be exposed as a define in
-     firewire.h?
+1. This driver uses the same ids that the firewire core does (001f11:0239xx).
+   Perhaps this could be exposed as a define in firewire.h?
diff --git a/drivers/staging/fwserial/fwserial.c b/drivers/staging/fwserial/fwserial.c
index 73deae3..2964366 100644
--- a/drivers/staging/fwserial/fwserial.c
+++ b/drivers/staging/fwserial/fwserial.c
@@ -30,8 +30,8 @@

 #define be32_to_u64(hi, lo)  ((u64)be32_to_cpu(hi) << 32 | be32_to_cpu(lo))

-#define LINUX_VENDOR_ID   0xd00d1eU  /* same id used in card root directory   */
-#define FWSERIAL_VERSION  0x00e81cU  /* must be unique within LINUX_VENDOR_ID */
+#define LINUX_VENDOR_ID   0x001f11U  /* same id used in card root directory   */
+#define FWSERIAL_VERSION  0x023953U  /* must be unique within LINUX_VENDOR_ID */

 /* configurable options */
 static int num_ttys = 4;	    /* # of std ttys to create per fw_card    */

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] staging/fwserial: use correct vendor/version IDs
  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-07  9:10   ` Greg Kroah-Hartman
  2 siblings, 0 replies; 7+ messages in thread
From: Stefan Richter @ 2015-01-29  9:44 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Clemens Ladisch, Peter Hurley, devel, linux1394-devel, linux-kernel

On Jan 28 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
> 
> Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
> ---
[...]
> --- a/drivers/staging/fwserial/fwserial.c
> +++ b/drivers/staging/fwserial/fwserial.c
> @@ -30,8 +30,8 @@
> 
>  #define be32_to_u64(hi, lo)  ((u64)be32_to_cpu(hi) << 32 | be32_to_cpu(lo))
> 
> -#define LINUX_VENDOR_ID   0xd00d1eU  /* same id used in card root directory   */
> -#define FWSERIAL_VERSION  0x00e81cU  /* must be unique within LINUX_VENDOR_ID */
> +#define LINUX_VENDOR_ID   0x001f11U  /* same id used in card root directory   */
> +#define FWSERIAL_VERSION  0x023953U  /* must be unique within LINUX_VENDOR_ID */

(Bikeshedding:  Per IEEE Registration Authority's list, 001f11 is not a
"Linux vendor ID" but Openmoko, Inc.'s vendor ID.)

Greg,
just FYI, the comment "same id used in card root directory" will remain
true only once a corresponding change to firewire-core was merged.
Proposed patch: http://marc.info/?l=linux1394-devel&m=142247554618207
(If I receive no substantial objections, this will go in in the next
merge window.)

Date: Wed, 28 Jan 2015 21:04:48 +0100
From: Clemens Ladisch <clemens@ladisch.de>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
CC: linux1394-devel@lists.sourceforge.net
Subject: [PATCH] firewire: core: use correct vendor/model IDs

The kernel was using the vendor ID 0xd00d1e, which was inherited from
the old ieee1394 driver stack.  However, this ID was not registered, and
invalid.

Instead, use the vendor/model IDs that are now officially assigned to
the kernel:
https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
---
 drivers/firewire/core-transaction.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firewire/core-transaction.c b/drivers/firewire/core-transaction.c
index 60f6963..99d9d8c7 100644
--- a/drivers/firewire/core-transaction.c
+++ b/drivers/firewire/core-transaction.c
@@ -1271,14 +1271,14 @@ static u32 model_textual_descriptor[3 + 64/4] = {

 static struct fw_descriptor vendor_id_descriptor = {
 	.length = ARRAY_SIZE(vendor_textual_descriptor),
-	.immediate = 0x03d00d1e,
+	.immediate = 0x03001f11,
 	.key = 0x81000000,
 	.data = vendor_textual_descriptor,
 };

 static struct fw_descriptor model_id_descriptor = {
 	.length = ARRAY_SIZE(model_textual_descriptor),
-	.immediate = 0x17000001,
+	.immediate = 0x17023901,
 	.key = 0x81000000,
 	.data = model_textual_descriptor,
 };

-- 
Stefan Richter
-=====-===== ---= ===-=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] staging/fwserial: use correct vendor/version IDs
  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-07  9:10   ` Greg Kroah-Hartman
  2 siblings, 1 reply; 7+ messages in thread
From: Peter Hurley @ 2015-02-02 22:08 UTC (permalink / raw)
  To: Clemens Ladisch, Greg Kroah-Hartman
  Cc: Stefan Richter, devel, linux1394-devel, linux-kernel

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.

Regards,
Peter Hurley





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] staging/fwserial: use correct vendor/version IDs
  2015-02-02 22:08   ` Peter Hurley
@ 2015-02-03  8:44     ` Stefan Richter
  2015-02-03 14:00       ` Peter Hurley
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Richter @ 2015-02-03  8:44 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Clemens Ladisch, Greg Kroah-Hartman, devel, linux1394-devel,
	linux-kernel

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).

Both fwserial-the-implementation and fwserial-the-protocol are your own,
and as yet unmerged.  (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.
-- 
Stefan Richter
-=====-===== --=- ---==
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] staging/fwserial: use correct vendor/version IDs
  2015-02-03  8:44     ` Stefan Richter
@ 2015-02-03 14:00       ` Peter Hurley
  2015-02-03 21:22         ` Stefan Richter
  0 siblings, 1 reply; 7+ messages in thread
From: Peter Hurley @ 2015-02-03 14:00 UTC (permalink / raw)
  To: Stefan Richter
  Cc: Clemens Ladisch, Greg Kroah-Hartman, devel, linux1394-devel,
	linux-kernel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] staging/fwserial: use correct vendor/version IDs
  2015-02-03 14:00       ` Peter Hurley
@ 2015-02-03 21:22         ` Stefan Richter
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Richter @ 2015-02-03 21:22 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Clemens Ladisch, Greg Kroah-Hartman, devel, linux1394-devel,
	linux-kernel

On Feb 03 Peter Hurley wrote:
> On 02/03/2015 03:44 AM, Stefan Richter wrote:
> > On Feb 02 Peter Hurley wrote:
[...]
> >> 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.

This ID has never been in use to identify the specifier of a unit
architecture though, nor has it been used otherwise in any protocol.
And the way how the ID /was/ used doesn't make it an OUI.

[Since 7.5 years ago the new firewire-core puts a fixed, unregistered
value into the config ROM's root dir's vendor ID leaf, whereas until
4 years ago ieee1394 has been copying the upper 24 bits of the node's
EUI-64 there.  Years counted according to mainline Linux releases.
As another historical note, 7.5 years ago the occupied OUI space consisted
of 10456 IDs from 0…acde48, now it is 19896 IDs from 0…fcffaa.]

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

If there is one or another patch among them which directly blocks your
work on fwserial, ping me so that I can reconsider priorities.  Though if
you were just expressing dissatisfaction with the subsystem's maintenance
progress, well, then that's noted and quite agreed.

> >  (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.

The difference of course is nothing more than that the interoperability of
the specifier_ID:software_version tuple either depends on made-up IDs, or
on IDs whose uniqueness is based on a proper chain of registrations.
-- 
Stefan Richter
-=====-===== --=- ---==
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] staging/fwserial: use correct vendor/version IDs
  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-07  9:10   ` Greg Kroah-Hartman
  2 siblings, 0 replies; 7+ messages in thread
From: Greg Kroah-Hartman @ 2015-02-07  9:10 UTC (permalink / raw)
  To: Clemens Ladisch
  Cc: Peter Hurley, Stefan Richter, devel, linux1394-devel, linux-kernel

On Wed, Jan 28, 2015 at 09:07:43PM +0100, 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
> 
> Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
> ---
>  drivers/staging/fwserial/TODO       |    5 ++---
>  drivers/staging/fwserial/fwserial.c |    4 ++--
>  2 files changed, 4 insertions(+), 5 deletions(-)

I'm dropping this from my queue until you all agree that I can apply it.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-02-07 17:11 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
2015-02-03 21:22         ` Stefan Richter
2015-02-07  9:10   ` Greg Kroah-Hartman

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).