Received-SPF: pass (google.com: domain of linux-kernel+bounces-147256-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 16 Apr 2024 18:42:48 +0200
From: Francesco Valla <valla.francesco@gmail.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Vincent Mailhol <vincent.mailhol@gmail.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>, linux-can@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Simon Horman <horms@kernel.org>,
	Bagas Sanjaya <bagasdotme@gmail.com>, fabio@redaril.me
Subject: Re: [PATCH v2 1/1] Documentation: networking: document ISO
 15765-2:2016
Message-ID: <Zh6qiDwbEnaJtTvl@fedora>
References: <20240329133458.323041-2-valla.francesco@gmail.com>
 <20240329133458.323041-3-valla.francesco@gmail.com>
 <CAMZ6RqKLaYb+8EaeoFMHofcaBT5G2-qdqSb4do73xrgMvWMZaA@mail.gmail.com>
 <9f5ad308-f2a0-47be-85f3-d152bc98099a@hartkopp.net>
 <CAMZ6RqKGKcYd4hAM8AVV72t78H-Kt92NXowx6Q+YCw=AuSxKuw@mail.gmail.com>
 <64586257-3cf6-4c10-a30b-200b1ecc5e80@hartkopp.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <64586257-3cf6-4c10-a30b-200b1ecc5e80@hartkopp.net>

On Sun, Apr 14, 2024 at 10:21:33PM +0200, Oliver Hartkopp wrote:
> 
> 
> On 14.04.24 06:03, Vincent Mailhol wrote:
> 
> > 
> > This doesn't remove the fact that I think that this naming convention
> > is stupid because of the RAS syndrome, but I acknowledge that CAN CC
> > is now the official denomination and thus, that we should adopt it in
> > our documentation as well.
> > 
> 
> ;-)
> 
>

I honestly did not knwow the new CAN in Automation naming scheme. Will
keep the CAN-CC here. Thanks!

> > > > Add a space between ISO and the number. Also, update the year:
> > > > 
> > > >     ISO 15765-2:2024
> > > > 
> > > 
> > > Interesting! Didn't know there's already a new version.
> > > 
> > > Will check this out whether we really support ISO 15765-2:2024 ...
> > > 
> > > Do you have the standard at hand right now or should we leave this as
> > > ISO15765-2:2016 until we know?
> > 
> > I have access to the newer revisions. But I never really invested time
> > into reading that standard (neither the 2016 nor the 2024 versions).
> > 
> > Regardless, here is a verbatim extract from the Foreworld section of
> > ISO 15765-2:2024
> > 
> >    This fourth edition cancels and replaces the third edition (ISO
> >    15765-2:2016), which has been technically revised.
> > 
> >    The main changes are as follows:
> > 
> >      - restructured the document to achieve compatibility with OSI
> >        7-layers model;
> > 
> >      - introduced T_Data abstract service primitive interface to
> >        achieve compatibility with ISO 14229-2;
> > 
> >      - moved all transport layer protocol-related information to Clause 9;
> > 
> >      - clarification and editorial corrections
> > 
> 
> Yes, I've checked the release notes on the ISO website too.
> This really looks like editorial stuff that has nothing to do with the data
> protocol and its segmentation.
> 

The :2016 suffix is cited both here and inside the Kconfig. We can:
- keep the :2016 here and then update both the documentation and the
  Kconfig once the standard has been checked
- move to :2024 both here and inside the Kconfig
- drop the :2016 from everywhere (leaving only ISO 15765) and move to
  ISO 15765:2024 only inside the "Specifications used" paragraph

What do you think? Shall the modifications to the Kconfig be done as part of
this series?


Best regards,
Francesco Valla