10:29 a.m.
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
Hi,
As part of the ongoing rebase effort, the following configuration
options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed
configuration options from the pending directory to the ark directory.
In the diff below, options are removed from the pending directory and
added to the ark hierarchy. The final options that need to be ACKed
are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply
with a better option.
CONFIG_CAN_ISOTP:
CAN Transport Protocols offer support for segmented Point-to-Point
communication between CAN nodes via two defined CAN Identifiers.
As CAN frames can only transport a small amount of data bytes
(max. 8 bytes for 'classic' CAN and max. 64 bytes for CAN FD) this
segmentation is needed to transport longer PDUs as needed e.g. for
vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN traffic.
This protocol driver implements data transfers according to
ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types.
If you want to perform automotive vehicle diagnostic services (UDS),
say 'y'.
Symbol: CAN_ISOTP [=n]
Type : tristate
Defined at net/can/Kconfig:58
Prompt: ISO 15765-2:2016 CAN transport protocol
Depends on: NET [=y] && CAN [=m]
Location:
-> Networking support (NET [=y])
-> CAN bus subsystem support (CAN [=m])
---
Cc: Jiri Benc <jbenc(a)redhat.com>
Cc: Marcelo Leitner <mleitner(a)redhat.com>
Cc: Davide Caratti <dcaratti(a)redhat.com>
Cc: Eric Garver <egarver(a)redhat.com>
Cc: Flavio Leitner <fbl(a)redhat.com>
Cc: Florian Westphal <fwestpha(a)redhat.com>
Cc: Guillaume Nault <gnault(a)redhat.com>
Cc: Hangbin Liu <haliu(a)redhat.com>
Cc: Ivan Vecera <ivecera(a)redhat.com>
Cc: Jarod Wilson <jarod(a)redhat.com>
Cc: Lorenzo Bianconi <lorenzo.bianconi(a)redhat.com>
Cc: Paolo Abeni <pabeni(a)redhat.com>
Cc: Phil Sutter <psutter(a)redhat.com>
Cc: Sabrina Dubroca <sdubroca(a)redhat.com>
Cc: Stefano Brivio <sbrivio(a)redhat.com>
Cc: Xin Long <lxin(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
.../configs/common/generic/CONFIG_CAN_ISOTP | 1 +
.../pending-common/generic/CONFIG_CAN_ISOTP | 25 -------------------
2 files changed, 1 insertion(+), 25 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_CAN_ISOTP
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_CAN_ISOTP
diff --git a/redhat/configs/common/generic/CONFIG_CAN_ISOTP
b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
new file mode 100644
index 000000000000..2ebf8768a868
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
@@ -0,0 +1 @@
+# CONFIG_CAN_ISOTP is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_CAN_ISOTP
b/redhat/configs/pending-common/generic/CONFIG_CAN_ISOTP
deleted file mode 100644
index 58dd572e7fc7..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_CAN_ISOTP
+++ /dev/null
@@ -1,25 +0,0 @@
-# CONFIG_CAN_ISOTP:
-#
-# CAN Transport Protocols offer support for segmented Point-to-Point
-# communication between CAN nodes via two defined CAN Identifiers.
-# As CAN frames can only transport a small amount of data bytes
-# (max. 8 bytes for 'classic' CAN and max. 64 bytes for CAN FD) this
-# segmentation is needed to transport longer PDUs as needed e.g. for
-# vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN traffic.
-# This protocol driver implements data transfers according to
-# ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types.
-# If you want to perform automotive vehicle diagnostic services (UDS),
-# say 'y'.
-#
-# Symbol: CAN_ISOTP [=n]
-# Type : tristate
-# Defined at net/can/Kconfig:58
-# Prompt: ISO 15765-2:2016 CAN transport protocol
-# Depends on: NET [=y] && CAN [=m]
-# Location:
-# -> Networking support (NET [=y])
-# -> CAN bus subsystem support (CAN [=m])
-#
-#
-#
-# CONFIG_CAN_ISOTP is not set
--
GitLab
11:33 a.m.
On Fri, Oct 16, 2020 at 03:29:56PM -0000, GitLab Bridge on behalf of jeremycline wrote:
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
@@ -0,0 +1 @@
+# CONFIG_CAN_ISOTP is not set
I'm not aware of any reason for it to be enabled, so
Acked-by: Marcelo Ricardo Leitner <mleitner(a)redhat.com>
12:19 p.m.
On Mon, Oct 19, 2020 at 5:33 PM Marcelo Ricardo Leitner
<mleitner(a)redhat.com> wrote:
On Fri, Oct 16, 2020 at 03:29:56PM -0000, GitLab Bridge on behalf of jeremycline wrote:
> --- /dev/null
> +++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
> @@ -0,0 +1 @@
> +# CONFIG_CAN_ISOTP is not set
I'm not aware of any reason for it to be enabled, so
Reading the description [1] if CAN is enabled you likely do want to
enable it as it enables the ability to segment up packages to support
protocols like IP over CAN.
Peter
[1] https://cateee.net/lkddb/web-lkddb/CAN_ISOTP.html
12:29 p.m.
On Mon, Oct 19, 2020 at 06:19:39PM +0100, Peter Robinson wrote:
On Mon, Oct 19, 2020 at 5:33 PM Marcelo Ricardo Leitner
<mleitner(a)redhat.com> wrote:
>
> On Fri, Oct 16, 2020 at 03:29:56PM -0000, GitLab Bridge on behalf of jeremycline
wrote:
> > --- /dev/null
> > +++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
> > @@ -0,0 +1 @@
> > +# CONFIG_CAN_ISOTP is not set
>
> I'm not aware of any reason for it to be enabled, so
Reading the description [1] if CAN is enabled you likely do want to
enable it as it enables the ability to segment up packages to support
protocols like IP over CAN.
This "likely" varies. I understand that it adds functionality, yes,
but enabling it means extra work to support it and I'm not aware of
any use case for it with RHEL. For Fedora that may be a different
story, but then I expect someone more Fedora-centric to chime in.
That said, maybe you are saying it should be on for Fedora?
Marcelo
12:36 p.m.
On Mon, Oct 19, 2020 at 6:29 PM Marcelo Ricardo Leitner
<mleitner(a)redhat.com> wrote:
On Mon, Oct 19, 2020 at 06:19:39PM +0100, Peter Robinson wrote:
> On Mon, Oct 19, 2020 at 5:33 PM Marcelo Ricardo Leitner
> <mleitner(a)redhat.com> wrote:
> >
> > On Fri, Oct 16, 2020 at 03:29:56PM -0000, GitLab Bridge on behalf of
jeremycline wrote:
> > > --- /dev/null
> > > +++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
> > > @@ -0,0 +1 @@
> > > +# CONFIG_CAN_ISOTP is not set
> >
> > I'm not aware of any reason for it to be enabled, so
>
> Reading the description [1] if CAN is enabled you likely do want to
> enable it as it enables the ability to segment up packages to support
> protocols like IP over CAN.
This "likely" varies. I understand that it adds functionality, yes,
but enabling it means extra work to support it and I'm not aware of
any use case for it with RHEL. For Fedora that may be a different
story, but then I expect someone more Fedora-centric to chime in.
I think it should be reviewed for RHEL, the RHEL for Edge initiative
has CAN on it's roadmap amongst other things in the el9 timeframe. If
you''re enabling CAN it should be functional for the majority of
useful usecases or just disable it completely.
12:54 p.m.
On Mon, Oct 19, 2020 at 06:36:45PM +0100, Peter Robinson wrote:
On Mon, Oct 19, 2020 at 6:29 PM Marcelo Ricardo Leitner
<mleitner(a)redhat.com> wrote:
>
> On Mon, Oct 19, 2020 at 06:19:39PM +0100, Peter Robinson wrote:
> > On Mon, Oct 19, 2020 at 5:33 PM Marcelo Ricardo Leitner
> > <mleitner(a)redhat.com> wrote:
> > >
> > > On Fri, Oct 16, 2020 at 03:29:56PM -0000, GitLab Bridge on behalf of
jeremycline wrote:
> > > > --- /dev/null
> > > > +++ b/redhat/configs/common/generic/CONFIG_CAN_ISOTP
> > > > @@ -0,0 +1 @@
> > > > +# CONFIG_CAN_ISOTP is not set
> > >
> > > I'm not aware of any reason for it to be enabled, so
> >
> > Reading the description [1] if CAN is enabled you likely do want to
> > enable it as it enables the ability to segment up packages to support
> > protocols like IP over CAN.
>
> This "likely" varies. I understand that it adds functionality, yes,
> but enabling it means extra work to support it and I'm not aware of
> any use case for it with RHEL. For Fedora that may be a different
> story, but then I expect someone more Fedora-centric to chime in.
I think it should be reviewed for RHEL, the RHEL for Edge initiative
has CAN on it's roadmap amongst other things in the el9 timeframe. If
Please share (off-list) some points on that. I'm all ears.
you''re enabling CAN it should be functional for the majority
of
useful usecases or just disable it completely.
Uhh.. so a new feature suddenly covers the majority of the useful
usecases? For those you care about, maybe yes, but please don't ignore
the rest.
Anyhow, please share the use cases you're seeing. Maybe it should be
enabled, yes, but we can't enable it just because it looks nice and
adds extra functionality, that may or may not be used. The enablement
doesn't end with turning this option on and more work is likely
needed. For instance, we have 0 test coverage for this feature now.
Marcelo
1282
days inactive
1285
days old
kernel@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
GitLab Bridge on behalf of jeremycline -
Marcelo Ricardo Leitner -
Peter Robinson