diff mbox series

[v4,3/7] can: bittiming: move bittiming calculation functions to calc_bittiming.c

Message ID 20220603102848.17907-4-mailhol.vincent@wanadoo.fr (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series can: refactoring of can-dev module and of Kbuild | expand

Checks

Context Check Description
netdev/tree_selection success Series ignored based on subject, async

Commit Message

Vincent Mailhol June 3, 2022, 10:28 a.m. UTC
The canonical way to select or deselect an object during compilation
is to use this pattern in the relevant Makefile:

bar-$(CONFIG_FOO) := foo.o

bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.

Create a new file named calc_bittiming.c with all the functions which
are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
Makefile according to above pattern.

Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
---
 drivers/net/can/Kconfig              |   4 +
 drivers/net/can/dev/Makefile         |   2 +
 drivers/net/can/dev/bittiming.c      | 197 --------------------------
 drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++
 4 files changed, 208 insertions(+), 197 deletions(-)
 create mode 100644 drivers/net/can/dev/calc_bittiming.c

Comments

Marc Kleine-Budde June 4, 2022, 11:25 a.m. UTC | #1
On 03.06.2022 19:28:44, Vincent Mailhol wrote:
> The canonical way to select or deselect an object during compilation
> is to use this pattern in the relevant Makefile:
> 
> bar-$(CONFIG_FOO) := foo.o
> 
> bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.
> 
> Create a new file named calc_bittiming.c with all the functions which
> are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
> Makefile according to above pattern.
> 
> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
> ---
>  drivers/net/can/Kconfig              |   4 +
>  drivers/net/can/dev/Makefile         |   2 +
>  drivers/net/can/dev/bittiming.c      | 197 --------------------------
>  drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++
>  4 files changed, 208 insertions(+), 197 deletions(-)
>  create mode 100644 drivers/net/can/dev/calc_bittiming.c
> 
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index b1e47f6c5586..8f3b97aea638 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING
>  	  source clock frequencies. Disabling saves some space, but then the
>  	  bit-timing parameters must be specified directly using the Netlink
>  	  arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
> +
> +	  The additional features selected by this option will be added to the
> +	  can-dev module.
> +
>  	  If unsure, say Y.
>  
>  config CAN_AT91
> diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile
> index 919f87e36eed..b8a55b1d90cd 100644
> --- a/drivers/net/can/dev/Makefile
> +++ b/drivers/net/can/dev/Makefile
> @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o
>  can-dev-$(CONFIG_CAN_NETLINK) += length.o
>  can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
>  can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o
> +
> +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o

Nitpick:
Can we keep this list sorted?

Marc
Vincent Mailhol June 4, 2022, 12:21 p.m. UTC | #2
On Sat. 4 June 2022 at 20:25, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 03.06.2022 19:28:44, Vincent Mailhol wrote:
> > The canonical way to select or deselect an object during compilation
> > is to use this pattern in the relevant Makefile:
> >
> > bar-$(CONFIG_FOO) := foo.o
> >
> > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.
> >
> > Create a new file named calc_bittiming.c with all the functions which
> > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
> > Makefile according to above pattern.
> >
> > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
> > ---
> >  drivers/net/can/Kconfig              |   4 +
> >  drivers/net/can/dev/Makefile         |   2 +
> >  drivers/net/can/dev/bittiming.c      | 197 --------------------------
> >  drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++
> >  4 files changed, 208 insertions(+), 197 deletions(-)
> >  create mode 100644 drivers/net/can/dev/calc_bittiming.c
> >
> > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> > index b1e47f6c5586..8f3b97aea638 100644
> > --- a/drivers/net/can/Kconfig
> > +++ b/drivers/net/can/Kconfig
> > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING
> >         source clock frequencies. Disabling saves some space, but then the
> >         bit-timing parameters must be specified directly using the Netlink
> >         arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
> > +
> > +       The additional features selected by this option will be added to the
> > +       can-dev module.
> > +
> >         If unsure, say Y.
> >
> >  config CAN_AT91
> > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile
> > index 919f87e36eed..b8a55b1d90cd 100644
> > --- a/drivers/net/can/dev/Makefile
> > +++ b/drivers/net/can/dev/Makefile
> > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> >  can-dev-$(CONFIG_CAN_NETLINK) += length.o
> >  can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> >  can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o
> > +
> > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
>
> Nitpick:
> Can we keep this list sorted?

My idea was first to group per CONFIG symbol according to the
different levels: CAN_DEV first, then CAN_NETLINK and finally
CAN_CALC_BITTIMING and CAN_RX_OFFLOAD. And then only sort by
alphabetical order within each group.

By sorting the list, do literally mean to sort each line like this:

obj-$(CONFIG_CAN_DEV) += can-dev.o
can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
can-dev-$(CONFIG_CAN_DEV) += skb.o
can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
can-dev-$(CONFIG_CAN_NETLINK) += dev.o
can-dev-$(CONFIG_CAN_NETLINK) += length.o
can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o

or do you mean to sort by object name (ignoring the config symbol) like that:

obj-$(CONFIG_CAN_DEV) += can-dev.o
can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
can-dev-$(CONFIG_CAN_NETLINK) += dev.o
can-dev-$(CONFIG_CAN_NETLINK) += length.o
can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o
can-dev-$(CONFIG_CAN_DEV) += skb.o

?

(I honestly do not care so much how we sort the lines. My logic of
grouping first by CONFIG symbols seems more natural, but I am fine to
go with any other suggestion).
Marc Kleine-Budde June 4, 2022, 12:41 p.m. UTC | #3
On 04.06.2022 21:21:01, Vincent MAILHOL wrote:
> On Sat. 4 June 2022 at 20:25, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> > On 03.06.2022 19:28:44, Vincent Mailhol wrote:
> > > The canonical way to select or deselect an object during compilation
> > > is to use this pattern in the relevant Makefile:
> > >
> > > bar-$(CONFIG_FOO) := foo.o
> > >
> > > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.
> > >
> > > Create a new file named calc_bittiming.c with all the functions which
> > > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
> > > Makefile according to above pattern.
> > >
> > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
> > > ---
> > >  drivers/net/can/Kconfig              |   4 +
> > >  drivers/net/can/dev/Makefile         |   2 +
> > >  drivers/net/can/dev/bittiming.c      | 197 --------------------------
> > >  drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++
> > >  4 files changed, 208 insertions(+), 197 deletions(-)
> > >  create mode 100644 drivers/net/can/dev/calc_bittiming.c
> > >
> > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> > > index b1e47f6c5586..8f3b97aea638 100644
> > > --- a/drivers/net/can/Kconfig
> > > +++ b/drivers/net/can/Kconfig
> > > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING
> > >         source clock frequencies. Disabling saves some space, but then the
> > >         bit-timing parameters must be specified directly using the Netlink
> > >         arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
> > > +
> > > +       The additional features selected by this option will be added to the
> > > +       can-dev module.
> > > +
> > >         If unsure, say Y.
> > >
> > >  config CAN_AT91
> > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile
> > > index 919f87e36eed..b8a55b1d90cd 100644
> > > --- a/drivers/net/can/dev/Makefile
> > > +++ b/drivers/net/can/dev/Makefile
> > > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> > >  can-dev-$(CONFIG_CAN_NETLINK) += length.o
> > >  can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> > >  can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o
> > > +
> > > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> >
> > Nitpick:
> > Can we keep this list sorted?
> 
> My idea was first to group per CONFIG symbol according to the
> different levels: CAN_DEV first, then CAN_NETLINK and finally
> CAN_CALC_BITTIMING and CAN_RX_OFFLOAD. And then only sort by
> alphabetical order within each group.

I was thinking to order by CONFIG symbol and put the objects without an
additional symbol first

> By sorting the list, do literally mean to sort each line like this:
> 
> obj-$(CONFIG_CAN_DEV) += can-dev.o
> can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> can-dev-$(CONFIG_CAN_DEV) += skb.o
> can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
> can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> can-dev-$(CONFIG_CAN_NETLINK) += length.o
> can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o

...which results in:

obj-$(CONFIG_CAN_DEV) += can-dev.o

can-dev-y += skb.o

can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
can-dev-$(CONFIG_CAN_NETLINK) += dev.o
can-dev-$(CONFIG_CAN_NETLINK) += length.o
can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o

> or do you mean to sort by object name (ignoring the config symbol) like that:
> 
> obj-$(CONFIG_CAN_DEV) += can-dev.o
> can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
> can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> can-dev-$(CONFIG_CAN_NETLINK) += length.o
> can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o
> can-dev-$(CONFIG_CAN_DEV) += skb.o
> 
> ?
> 
> (I honestly do not care so much how we sort the lines. My logic of
> grouping first by CONFIG symbols seems more natural, but I am fine to
> go with any other suggestion).

I think this makes it clear where new files should be added.

Marc
Vincent Mailhol June 4, 2022, 12:56 p.m. UTC | #4
On Sat. 4 June 2022 at 21:41, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 04.06.2022 21:21:01, Vincent MAILHOL wrote:
> > On Sat. 4 June 2022 at 20:25, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> > > On 03.06.2022 19:28:44, Vincent Mailhol wrote:
> > > > The canonical way to select or deselect an object during compilation
> > > > is to use this pattern in the relevant Makefile:
> > > >
> > > > bar-$(CONFIG_FOO) := foo.o
> > > >
> > > > bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.
> > > >
> > > > Create a new file named calc_bittiming.c with all the functions which
> > > > are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
> > > > Makefile according to above pattern.
> > > >
> > > > Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
> > > > ---
> > > >  drivers/net/can/Kconfig              |   4 +
> > > >  drivers/net/can/dev/Makefile         |   2 +
> > > >  drivers/net/can/dev/bittiming.c      | 197 --------------------------
> > > >  drivers/net/can/dev/calc_bittiming.c | 202 +++++++++++++++++++++++++++
> > > >  4 files changed, 208 insertions(+), 197 deletions(-)
> > > >  create mode 100644 drivers/net/can/dev/calc_bittiming.c
> > > >
> > > > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> > > > index b1e47f6c5586..8f3b97aea638 100644
> > > > --- a/drivers/net/can/Kconfig
> > > > +++ b/drivers/net/can/Kconfig
> > > > @@ -96,6 +96,10 @@ config CAN_CALC_BITTIMING
> > > >         source clock frequencies. Disabling saves some space, but then the
> > > >         bit-timing parameters must be specified directly using the Netlink
> > > >         arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
> > > > +
> > > > +       The additional features selected by this option will be added to the
> > > > +       can-dev module.
> > > > +
> > > >         If unsure, say Y.
> > > >
> > > >  config CAN_AT91
> > > > diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile
> > > > index 919f87e36eed..b8a55b1d90cd 100644
> > > > --- a/drivers/net/can/dev/Makefile
> > > > +++ b/drivers/net/can/dev/Makefile
> > > > @@ -9,3 +9,5 @@ can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> > > >  can-dev-$(CONFIG_CAN_NETLINK) += length.o
> > > >  can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> > > >  can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o
> > > > +
> > > > +can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> > >
> > > Nitpick:
> > > Can we keep this list sorted?
> >
> > My idea was first to group per CONFIG symbol according to the
> > different levels: CAN_DEV first, then CAN_NETLINK and finally
> > CAN_CALC_BITTIMING and CAN_RX_OFFLOAD. And then only sort by
> > alphabetical order within each group.
>
> I was thinking to order by CONFIG symbol and put the objects without an
> additional symbol first
>
> > By sorting the list, do literally mean to sort each line like this:
> >
> > obj-$(CONFIG_CAN_DEV) += can-dev.o
> > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> > can-dev-$(CONFIG_CAN_DEV) += skb.o
> > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
> > can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> > can-dev-$(CONFIG_CAN_NETLINK) += length.o
> > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o
>
> ...which results in:
>
> obj-$(CONFIG_CAN_DEV) += can-dev.o
>
> can-dev-y += skb.o

I see. But this contradicts the idea to do
| obj-y += can-dev
as suggested in:
https://lore.kernel.org/linux-can/20220604112707.z4zjdjydqy5rkyfe@pengutronix.de/

So, we have to choose between:
| obj-$(CONFIG_CAN_DEV) += can-dev.o
|
| can-dev-y += skb.o
|
| can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
| (...)

or:

| obj-y += can-dev.o
|
| can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
| can-dev-$(CONFIG_CAN_DEV) += skb.o
| (...)

I have a slight preference for the second, but again, wouldn't mind to
select the first one.

> can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
> can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> can-dev-$(CONFIG_CAN_NETLINK) += length.o
> can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o
>
> > or do you mean to sort by object name (ignoring the config symbol) like that:
> >
> > obj-$(CONFIG_CAN_DEV) += can-dev.o
> > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
> > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> > can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> > can-dev-$(CONFIG_CAN_NETLINK) += length.o
> > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o
> > can-dev-$(CONFIG_CAN_DEV) += skb.o
> >
> > ?
> >
> > (I honestly do not care so much how we sort the lines. My logic of
> > grouping first by CONFIG symbols seems more natural, but I am fine to
> > go with any other suggestion).
>
> I think this makes it clear where new files should be added.
>
> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde           |
> Embedded Linux                   | https://www.pengutronix.de  |
> Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |
Marc Kleine-Budde June 4, 2022, 1:51 p.m. UTC | #5
On 04.06.2022 21:56:23, Vincent MAILHOL wrote:
> > I was thinking to order by CONFIG symbol and put the objects without an
> > additional symbol first
> >
> > > By sorting the list, do literally mean to sort each line like this:
> > >
> > > obj-$(CONFIG_CAN_DEV) += can-dev.o
> > > can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> > > can-dev-$(CONFIG_CAN_DEV) += skb.o
> > > can-dev-$(CONFIG_CAN_NETLINK) += bittiming.o
> > > can-dev-$(CONFIG_CAN_NETLINK) += dev.o
> > > can-dev-$(CONFIG_CAN_NETLINK) += length.o
> > > can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
> > > can-dev-$(CONFIG_CAN_RX_OFFLOAD) += rx-offload.o
> >
> > ...which results in:
> >
> > obj-$(CONFIG_CAN_DEV) += can-dev.o
> >
> > can-dev-y += skb.o
> 
> I see. But this contradicts the idea to do
> | obj-y += can-dev
> as suggested in:
> https://lore.kernel.org/linux-can/20220604112707.z4zjdjydqy5rkyfe@pengutronix.de/

Doh! That mail was totally wrong - I've send an updated version.

> So, we have to choose between:
> | obj-$(CONFIG_CAN_DEV) += can-dev.o
> |
> | can-dev-y += skb.o
> |
> | can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> | (...)

+1

> or:
> 
> | obj-y += can-dev.o
> |
> | can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
> | can-dev-$(CONFIG_CAN_DEV) += skb.o
> | (...)
> 
> I have a slight preference for the second, but again, wouldn't mind to
> select the first one.

I think if can-dev is added to "obj-y" it will be always complied into
the kernel. It will not be a module, if CONFIG_CAN_DEV configured as a
module (which results in $(CONFIG_CAN_DEV) evaluate to "m").

Sorry for the confusion!

Marc
diff mbox series

Patch

diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index b1e47f6c5586..8f3b97aea638 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -96,6 +96,10 @@  config CAN_CALC_BITTIMING
 	  source clock frequencies. Disabling saves some space, but then the
 	  bit-timing parameters must be specified directly using the Netlink
 	  arguments "tq", "prop_seg", "phase_seg1", "phase_seg2" and "sjw".
+
+	  The additional features selected by this option will be added to the
+	  can-dev module.
+
 	  If unsure, say Y.
 
 config CAN_AT91
diff --git a/drivers/net/can/dev/Makefile b/drivers/net/can/dev/Makefile
index 919f87e36eed..b8a55b1d90cd 100644
--- a/drivers/net/can/dev/Makefile
+++ b/drivers/net/can/dev/Makefile
@@ -9,3 +9,5 @@  can-dev-$(CONFIG_CAN_NETLINK) += dev.o
 can-dev-$(CONFIG_CAN_NETLINK) += length.o
 can-dev-$(CONFIG_CAN_NETLINK) += netlink.o
 can-dev-$(CONFIG_CAN_NETLINK) += rx-offload.o
+
+can-dev-$(CONFIG_CAN_CALC_BITTIMING) += calc_bittiming.o
diff --git a/drivers/net/can/dev/bittiming.c b/drivers/net/can/dev/bittiming.c
index c1e76f0a5064..7ae80763c960 100644
--- a/drivers/net/can/dev/bittiming.c
+++ b/drivers/net/can/dev/bittiming.c
@@ -4,205 +4,8 @@ 
  * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com>
  */
 
-#include <linux/units.h>
 #include <linux/can/dev.h>
 
-#ifdef CONFIG_CAN_CALC_BITTIMING
-#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */
-
-/* Bit-timing calculation derived from:
- *
- * Code based on LinCAN sources and H8S2638 project
- * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz
- * Copyright 2005      Stanislav Marek
- * email: pisa@cmp.felk.cvut.cz
- *
- * Calculates proper bit-timing parameters for a specified bit-rate
- * and sample-point, which can then be used to set the bit-timing
- * registers of the CAN controller. You can find more information
- * in the header file linux/can/netlink.h.
- */
-static int
-can_update_sample_point(const struct can_bittiming_const *btc,
-			const unsigned int sample_point_nominal, const unsigned int tseg,
-			unsigned int *tseg1_ptr, unsigned int *tseg2_ptr,
-			unsigned int *sample_point_error_ptr)
-{
-	unsigned int sample_point_error, best_sample_point_error = UINT_MAX;
-	unsigned int sample_point, best_sample_point = 0;
-	unsigned int tseg1, tseg2;
-	int i;
-
-	for (i = 0; i <= 1; i++) {
-		tseg2 = tseg + CAN_SYNC_SEG -
-			(sample_point_nominal * (tseg + CAN_SYNC_SEG)) /
-			1000 - i;
-		tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max);
-		tseg1 = tseg - tseg2;
-		if (tseg1 > btc->tseg1_max) {
-			tseg1 = btc->tseg1_max;
-			tseg2 = tseg - tseg1;
-		}
-
-		sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) /
-			(tseg + CAN_SYNC_SEG);
-		sample_point_error = abs(sample_point_nominal - sample_point);
-
-		if (sample_point <= sample_point_nominal &&
-		    sample_point_error < best_sample_point_error) {
-			best_sample_point = sample_point;
-			best_sample_point_error = sample_point_error;
-			*tseg1_ptr = tseg1;
-			*tseg2_ptr = tseg2;
-		}
-	}
-
-	if (sample_point_error_ptr)
-		*sample_point_error_ptr = best_sample_point_error;
-
-	return best_sample_point;
-}
-
-int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt,
-		       const struct can_bittiming_const *btc)
-{
-	struct can_priv *priv = netdev_priv(dev);
-	unsigned int bitrate;			/* current bitrate */
-	unsigned int bitrate_error;		/* difference between current and nominal value */
-	unsigned int best_bitrate_error = UINT_MAX;
-	unsigned int sample_point_error;	/* difference between current and nominal value */
-	unsigned int best_sample_point_error = UINT_MAX;
-	unsigned int sample_point_nominal;	/* nominal sample point */
-	unsigned int best_tseg = 0;		/* current best value for tseg */
-	unsigned int best_brp = 0;		/* current best value for brp */
-	unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0;
-	u64 v64;
-
-	/* Use CiA recommended sample points */
-	if (bt->sample_point) {
-		sample_point_nominal = bt->sample_point;
-	} else {
-		if (bt->bitrate > 800 * KILO /* BPS */)
-			sample_point_nominal = 750;
-		else if (bt->bitrate > 500 * KILO /* BPS */)
-			sample_point_nominal = 800;
-		else
-			sample_point_nominal = 875;
-	}
-
-	/* tseg even = round down, odd = round up */
-	for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1;
-	     tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) {
-		tsegall = CAN_SYNC_SEG + tseg / 2;
-
-		/* Compute all possible tseg choices (tseg=tseg1+tseg2) */
-		brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2;
-
-		/* choose brp step which is possible in system */
-		brp = (brp / btc->brp_inc) * btc->brp_inc;
-		if (brp < btc->brp_min || brp > btc->brp_max)
-			continue;
-
-		bitrate = priv->clock.freq / (brp * tsegall);
-		bitrate_error = abs(bt->bitrate - bitrate);
-
-		/* tseg brp biterror */
-		if (bitrate_error > best_bitrate_error)
-			continue;
-
-		/* reset sample point error if we have a better bitrate */
-		if (bitrate_error < best_bitrate_error)
-			best_sample_point_error = UINT_MAX;
-
-		can_update_sample_point(btc, sample_point_nominal, tseg / 2,
-					&tseg1, &tseg2, &sample_point_error);
-		if (sample_point_error >= best_sample_point_error)
-			continue;
-
-		best_sample_point_error = sample_point_error;
-		best_bitrate_error = bitrate_error;
-		best_tseg = tseg / 2;
-		best_brp = brp;
-
-		if (bitrate_error == 0 && sample_point_error == 0)
-			break;
-	}
-
-	if (best_bitrate_error) {
-		/* Error in one-tenth of a percent */
-		v64 = (u64)best_bitrate_error * 1000;
-		do_div(v64, bt->bitrate);
-		bitrate_error = (u32)v64;
-		if (bitrate_error > CAN_CALC_MAX_ERROR) {
-			netdev_err(dev,
-				   "bitrate error %d.%d%% too high\n",
-				   bitrate_error / 10, bitrate_error % 10);
-			return -EDOM;
-		}
-		netdev_warn(dev, "bitrate error %d.%d%%\n",
-			    bitrate_error / 10, bitrate_error % 10);
-	}
-
-	/* real sample point */
-	bt->sample_point = can_update_sample_point(btc, sample_point_nominal,
-						   best_tseg, &tseg1, &tseg2,
-						   NULL);
-
-	v64 = (u64)best_brp * 1000 * 1000 * 1000;
-	do_div(v64, priv->clock.freq);
-	bt->tq = (u32)v64;
-	bt->prop_seg = tseg1 / 2;
-	bt->phase_seg1 = tseg1 - bt->prop_seg;
-	bt->phase_seg2 = tseg2;
-
-	/* check for sjw user settings */
-	if (!bt->sjw || !btc->sjw_max) {
-		bt->sjw = 1;
-	} else {
-		/* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */
-		if (bt->sjw > btc->sjw_max)
-			bt->sjw = btc->sjw_max;
-		/* bt->sjw must not be higher than tseg2 */
-		if (tseg2 < bt->sjw)
-			bt->sjw = tseg2;
-	}
-
-	bt->brp = best_brp;
-
-	/* real bitrate */
-	bt->bitrate = priv->clock.freq /
-		(bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2));
-
-	return 0;
-}
-
-void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const,
-		   const struct can_bittiming *dbt,
-		   u32 *ctrlmode, u32 ctrlmode_supported)
-
-{
-	if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO))
-		return;
-
-	*ctrlmode &= ~CAN_CTRLMODE_TDC_MASK;
-
-	/* As specified in ISO 11898-1 section 11.3.3 "Transmitter
-	 * delay compensation" (TDC) is only applicable if data BRP is
-	 * one or two.
-	 */
-	if (dbt->brp == 1 || dbt->brp == 2) {
-		/* Sample point in clock periods */
-		u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg +
-					  dbt->phase_seg1) * dbt->brp;
-
-		if (sample_point_in_tc < tdc_const->tdco_min)
-			return;
-		tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max);
-		*ctrlmode |= CAN_CTRLMODE_TDC_AUTO;
-	}
-}
-#endif /* CONFIG_CAN_CALC_BITTIMING */
-
 /* Checks the validity of the specified bit-timing parameters prop_seg,
  * phase_seg1, phase_seg2 and sjw and tries to determine the bitrate
  * prescaler value brp. You can find more information in the header
diff --git a/drivers/net/can/dev/calc_bittiming.c b/drivers/net/can/dev/calc_bittiming.c
new file mode 100644
index 000000000000..d3caa040614d
--- /dev/null
+++ b/drivers/net/can/dev/calc_bittiming.c
@@ -0,0 +1,202 @@ 
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (C) 2005 Marc Kleine-Budde, Pengutronix
+ * Copyright (C) 2006 Andrey Volkov, Varma Electronics
+ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com>
+ */
+
+#include <linux/units.h>
+#include <linux/can/dev.h>
+
+#define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */
+
+/* Bit-timing calculation derived from:
+ *
+ * Code based on LinCAN sources and H8S2638 project
+ * Copyright 2004-2006 Pavel Pisa - DCE FELK CVUT cz
+ * Copyright 2005      Stanislav Marek
+ * email: pisa@cmp.felk.cvut.cz
+ *
+ * Calculates proper bit-timing parameters for a specified bit-rate
+ * and sample-point, which can then be used to set the bit-timing
+ * registers of the CAN controller. You can find more information
+ * in the header file linux/can/netlink.h.
+ */
+static int
+can_update_sample_point(const struct can_bittiming_const *btc,
+			const unsigned int sample_point_nominal, const unsigned int tseg,
+			unsigned int *tseg1_ptr, unsigned int *tseg2_ptr,
+			unsigned int *sample_point_error_ptr)
+{
+	unsigned int sample_point_error, best_sample_point_error = UINT_MAX;
+	unsigned int sample_point, best_sample_point = 0;
+	unsigned int tseg1, tseg2;
+	int i;
+
+	for (i = 0; i <= 1; i++) {
+		tseg2 = tseg + CAN_SYNC_SEG -
+			(sample_point_nominal * (tseg + CAN_SYNC_SEG)) /
+			1000 - i;
+		tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max);
+		tseg1 = tseg - tseg2;
+		if (tseg1 > btc->tseg1_max) {
+			tseg1 = btc->tseg1_max;
+			tseg2 = tseg - tseg1;
+		}
+
+		sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) /
+			(tseg + CAN_SYNC_SEG);
+		sample_point_error = abs(sample_point_nominal - sample_point);
+
+		if (sample_point <= sample_point_nominal &&
+		    sample_point_error < best_sample_point_error) {
+			best_sample_point = sample_point;
+			best_sample_point_error = sample_point_error;
+			*tseg1_ptr = tseg1;
+			*tseg2_ptr = tseg2;
+		}
+	}
+
+	if (sample_point_error_ptr)
+		*sample_point_error_ptr = best_sample_point_error;
+
+	return best_sample_point;
+}
+
+int can_calc_bittiming(const struct net_device *dev, struct can_bittiming *bt,
+		       const struct can_bittiming_const *btc)
+{
+	struct can_priv *priv = netdev_priv(dev);
+	unsigned int bitrate;			/* current bitrate */
+	unsigned int bitrate_error;		/* difference between current and nominal value */
+	unsigned int best_bitrate_error = UINT_MAX;
+	unsigned int sample_point_error;	/* difference between current and nominal value */
+	unsigned int best_sample_point_error = UINT_MAX;
+	unsigned int sample_point_nominal;	/* nominal sample point */
+	unsigned int best_tseg = 0;		/* current best value for tseg */
+	unsigned int best_brp = 0;		/* current best value for brp */
+	unsigned int brp, tsegall, tseg, tseg1 = 0, tseg2 = 0;
+	u64 v64;
+
+	/* Use CiA recommended sample points */
+	if (bt->sample_point) {
+		sample_point_nominal = bt->sample_point;
+	} else {
+		if (bt->bitrate > 800 * KILO /* BPS */)
+			sample_point_nominal = 750;
+		else if (bt->bitrate > 500 * KILO /* BPS */)
+			sample_point_nominal = 800;
+		else
+			sample_point_nominal = 875;
+	}
+
+	/* tseg even = round down, odd = round up */
+	for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1;
+	     tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) {
+		tsegall = CAN_SYNC_SEG + tseg / 2;
+
+		/* Compute all possible tseg choices (tseg=tseg1+tseg2) */
+		brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2;
+
+		/* choose brp step which is possible in system */
+		brp = (brp / btc->brp_inc) * btc->brp_inc;
+		if (brp < btc->brp_min || brp > btc->brp_max)
+			continue;
+
+		bitrate = priv->clock.freq / (brp * tsegall);
+		bitrate_error = abs(bt->bitrate - bitrate);
+
+		/* tseg brp biterror */
+		if (bitrate_error > best_bitrate_error)
+			continue;
+
+		/* reset sample point error if we have a better bitrate */
+		if (bitrate_error < best_bitrate_error)
+			best_sample_point_error = UINT_MAX;
+
+		can_update_sample_point(btc, sample_point_nominal, tseg / 2,
+					&tseg1, &tseg2, &sample_point_error);
+		if (sample_point_error >= best_sample_point_error)
+			continue;
+
+		best_sample_point_error = sample_point_error;
+		best_bitrate_error = bitrate_error;
+		best_tseg = tseg / 2;
+		best_brp = brp;
+
+		if (bitrate_error == 0 && sample_point_error == 0)
+			break;
+	}
+
+	if (best_bitrate_error) {
+		/* Error in one-tenth of a percent */
+		v64 = (u64)best_bitrate_error * 1000;
+		do_div(v64, bt->bitrate);
+		bitrate_error = (u32)v64;
+		if (bitrate_error > CAN_CALC_MAX_ERROR) {
+			netdev_err(dev,
+				   "bitrate error %d.%d%% too high\n",
+				   bitrate_error / 10, bitrate_error % 10);
+			return -EDOM;
+		}
+		netdev_warn(dev, "bitrate error %d.%d%%\n",
+			    bitrate_error / 10, bitrate_error % 10);
+	}
+
+	/* real sample point */
+	bt->sample_point = can_update_sample_point(btc, sample_point_nominal,
+						   best_tseg, &tseg1, &tseg2,
+						   NULL);
+
+	v64 = (u64)best_brp * 1000 * 1000 * 1000;
+	do_div(v64, priv->clock.freq);
+	bt->tq = (u32)v64;
+	bt->prop_seg = tseg1 / 2;
+	bt->phase_seg1 = tseg1 - bt->prop_seg;
+	bt->phase_seg2 = tseg2;
+
+	/* check for sjw user settings */
+	if (!bt->sjw || !btc->sjw_max) {
+		bt->sjw = 1;
+	} else {
+		/* bt->sjw is at least 1 -> sanitize upper bound to sjw_max */
+		if (bt->sjw > btc->sjw_max)
+			bt->sjw = btc->sjw_max;
+		/* bt->sjw must not be higher than tseg2 */
+		if (tseg2 < bt->sjw)
+			bt->sjw = tseg2;
+	}
+
+	bt->brp = best_brp;
+
+	/* real bitrate */
+	bt->bitrate = priv->clock.freq /
+		(bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2));
+
+	return 0;
+}
+
+void can_calc_tdco(struct can_tdc *tdc, const struct can_tdc_const *tdc_const,
+		   const struct can_bittiming *dbt,
+		   u32 *ctrlmode, u32 ctrlmode_supported)
+
+{
+	if (!tdc_const || !(ctrlmode_supported & CAN_CTRLMODE_TDC_AUTO))
+		return;
+
+	*ctrlmode &= ~CAN_CTRLMODE_TDC_MASK;
+
+	/* As specified in ISO 11898-1 section 11.3.3 "Transmitter
+	 * delay compensation" (TDC) is only applicable if data BRP is
+	 * one or two.
+	 */
+	if (dbt->brp == 1 || dbt->brp == 2) {
+		/* Sample point in clock periods */
+		u32 sample_point_in_tc = (CAN_SYNC_SEG + dbt->prop_seg +
+					  dbt->phase_seg1) * dbt->brp;
+
+		if (sample_point_in_tc < tdc_const->tdco_min)
+			return;
+		tdc->tdco = min(sample_point_in_tc, tdc_const->tdco_max);
+		*ctrlmode |= CAN_CTRLMODE_TDC_AUTO;
+	}
+}