This series adds emulation of the FlexCAN CAN controller, version 2,
found in NXP i.MX6 series SoCs. The controller is integrated into
fsl-imx6 and the Sabrelite ARM board.

The chip has two FlexCAN controllers, but the Linux Sabrelite
device tree enables only one by default. Linux kernel with both
controllers enabled has been tested to work properly (using a custom
device tree).
See docs/system/devices/can.rst for an example of QEMU command line
invocation.

More information about the implementation can be found in my bachelor
thesis [1].

The headers (struct FlexcanRegs and flexcan_regs.h macros) were copied
from the Linux kernel. Marc Kleine-Budde is the copyright holder. He
has been kindly asked to provide consent, to confirm his approval for
the inclusion of said header fragments into QEMU. The approval is still
pending, hopefully it will be resolved soon. I will update the patchset
on request if another wording/solution for the copyright statement is
proposed/requested.

Changes from v2:
- moved variable declarations to the top-of-the-block
- cleanup
- removed redundant license boilerplate
- rebased onto latest master
- Link to v2: https://lore.kernel.org/qemu-devel/cover.1773866323.git.matyas.bobek@gmail.com/

Changes from v1 to v2:
- removed DPRINTF (turned into traces or guest errors)
- removed gotos and unnecessary continues
- register memory region shortened to actual length w/o padding
- make flexcan_* fns private
- used DEVICE(s)->canonical_path instead of allocating new strings
- changed DEVICE_NATIVE_ENDIAN to DEVICE_LITTLE_ENDIAN
- removed ugly USE macro
- used enums instead of define sequences in flexcan.c
- fixed FlexCAN KConfig conf (fixes build on non-arm-softmmu)
- fixed style and other issues from Bernhard's review
- better wording in docs
- rebased onto latest master
- Link to v1: https://lore.kernel.org/qemu-devel/cover.1765826753.git.matyas.bobek@gmail.com

Thanks Bernhard Beschow for the review and his patience.
I borrowed some fixes from his flexcan branch at [2].

[1] http://dspace.cvut.cz/bitstream/handle/10467/122654/F3-BP-2025-Bobek-Matyas-BP_Bobek_FlexCAN_final_4.pdf
[2] https://github.com/shentok/qemu/tree/flexcan

Matyáš Bobek (7):
  hw/arm/sabrelite: Open code DEFINE_MACHINE_ARM
  hw/arm/sabrelite: Introduce class SabreliteMachineState
  hw/misc/imx6_ccm: Add PLL3 and CAN clock
  hw/net/can/flexcan: NXP FlexCAN core emulation
  hw/arm: Plug FlexCAN into FSL_IMX6 and Sabrelite
  tests: Add qtests for FlexCAN
  docs/arm/sabrelite: Mention FlexCAN support

 MAINTAINERS                   |    9 +
 docs/system/arm/sabrelite.rst |    1 +
 docs/system/devices/can.rst   |   24 +
 hw/arm/Kconfig                |    1 +
 hw/arm/fsl-imx6.c             |   29 +
 hw/arm/sabrelite.c            |   68 +-
 hw/misc/imx6_ccm.c            |   24 +
 hw/misc/trace-events          |    2 +
 hw/net/Kconfig                |    5 +
 hw/net/can/flexcan.c          | 1395 +++++++++++++++++++++++++++++++++
 hw/net/can/flexcan_regs.h     |  193 +++++
 hw/net/can/meson.build        |    1 +
 hw/net/can/trace-events       |   18 +
 include/hw/arm/fsl-imx6.h     |    6 +
 include/hw/misc/imx6_ccm.h    |    4 +
 include/hw/misc/imx_ccm.h     |    1 +
 include/hw/net/flexcan.h      |  139 ++++
 tests/qtest/flexcan-test.c    |  421 ++++++++++
 tests/qtest/meson.build       |    1 +
 19 files changed, 2332 insertions(+), 10 deletions(-)
 create mode 100644 hw/net/can/flexcan.c
 create mode 100644 hw/net/can/flexcan_regs.h
 create mode 100644 include/hw/net/flexcan.h
 create mode 100644 tests/qtest/flexcan-test.c

-- 
2.53.0

Am 30. April 2026 18:26:02 UTC schrieb "Matyáš Bobek" <matyas.bobek@gmail.com>:
>This series adds emulation of the FlexCAN CAN controller, version 2,
>found in NXP i.MX6 series SoCs. The controller is integrated into
>fsl-imx6 and the Sabrelite ARM board.
>
>The chip has two FlexCAN controllers, but the Linux Sabrelite
>device tree enables only one by default. Linux kernel with both
>controllers enabled has been tested to work properly (using a custom
>device tree).
>See docs/system/devices/can.rst for an example of QEMU command line
>invocation.
>
>More information about the implementation can be found in my bachelor
>thesis [1].
>
>The headers (struct FlexcanRegs and flexcan_regs.h macros) were copied
>from the Linux kernel. Marc Kleine-Budde is the copyright holder. He
>has been kindly asked to provide consent, to confirm his approval for
>the inclusion of said header fragments into QEMU. The approval is still
>pending, hopefully it will be resolved soon. I will update the patchset
>on request if another wording/solution for the copyright statement is
>proposed/requested.

Tested with imx8mp-evk: https://github.com/shentok/qemu/commits/imx8mp-flexcan/ which works excellent. Next step after this series is merged would be upstreaming that branch.

I guess the only open issue is the licensing of struct FlexcanRegs [1] which originates from Linux? How do we proceed here?

Best regards,
Bernhard

[1] https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.cz/

>
>Changes from v2:
>- moved variable declarations to the top-of-the-block
>- cleanup
>- removed redundant license boilerplate
>- rebased onto latest master
>- Link to v2: https://lore.kernel.org/qemu-devel/cover.1773866323.git.matyas.bobek@gmail.com/
>
>Changes from v1 to v2:
>- removed DPRINTF (turned into traces or guest errors)
>- removed gotos and unnecessary continues
>- register memory region shortened to actual length w/o padding
>- make flexcan_* fns private
>- used DEVICE(s)->canonical_path instead of allocating new strings
>- changed DEVICE_NATIVE_ENDIAN to DEVICE_LITTLE_ENDIAN
>- removed ugly USE macro
>- used enums instead of define sequences in flexcan.c
>- fixed FlexCAN KConfig conf (fixes build on non-arm-softmmu)
>- fixed style and other issues from Bernhard's review
>- better wording in docs
>- rebased onto latest master
>- Link to v1: https://lore.kernel.org/qemu-devel/cover.1765826753.git.matyas.bobek@gmail.com
>
>Thanks Bernhard Beschow for the review and his patience.
>I borrowed some fixes from his flexcan branch at [2].
>
>[1] http://dspace.cvut.cz/bitstream/handle/10467/122654/F3-BP-2025-Bobek-Matyas-BP_Bobek_FlexCAN_final_4.pdf
>[2] https://github.com/shentok/qemu/tree/flexcan
>
>Matyáš Bobek (7):
>  hw/arm/sabrelite: Open code DEFINE_MACHINE_ARM
>  hw/arm/sabrelite: Introduce class SabreliteMachineState
>  hw/misc/imx6_ccm: Add PLL3 and CAN clock
>  hw/net/can/flexcan: NXP FlexCAN core emulation
>  hw/arm: Plug FlexCAN into FSL_IMX6 and Sabrelite
>  tests: Add qtests for FlexCAN
>  docs/arm/sabrelite: Mention FlexCAN support
>
> MAINTAINERS                   |    9 +
> docs/system/arm/sabrelite.rst |    1 +
> docs/system/devices/can.rst   |   24 +
> hw/arm/Kconfig                |    1 +
> hw/arm/fsl-imx6.c             |   29 +
> hw/arm/sabrelite.c            |   68 +-
> hw/misc/imx6_ccm.c            |   24 +
> hw/misc/trace-events          |    2 +
> hw/net/Kconfig                |    5 +
> hw/net/can/flexcan.c          | 1395 +++++++++++++++++++++++++++++++++
> hw/net/can/flexcan_regs.h     |  193 +++++
> hw/net/can/meson.build        |    1 +
> hw/net/can/trace-events       |   18 +
> include/hw/arm/fsl-imx6.h     |    6 +
> include/hw/misc/imx6_ccm.h    |    4 +
> include/hw/misc/imx_ccm.h     |    1 +
> include/hw/net/flexcan.h      |  139 ++++
> tests/qtest/flexcan-test.c    |  421 ++++++++++
> tests/qtest/meson.build       |    1 +
> 19 files changed, 2332 insertions(+), 10 deletions(-)
> create mode 100644 hw/net/can/flexcan.c
> create mode 100644 hw/net/can/flexcan_regs.h
> create mode 100644 include/hw/net/flexcan.h
> create mode 100644 tests/qtest/flexcan-test.c
>

On Tue, 5 May 2026 at 19:03, Bernhard Beschow <shentey@gmail.com> wrote:
>
>
>
> Am 30. April 2026 18:26:02 UTC schrieb "Matyáš Bobek" <matyas.bobek@gmail.com>:
> >This series adds emulation of the FlexCAN CAN controller, version 2,
> >found in NXP i.MX6 series SoCs. The controller is integrated into
> >fsl-imx6 and the Sabrelite ARM board.
> >
> >The chip has two FlexCAN controllers, but the Linux Sabrelite
> >device tree enables only one by default. Linux kernel with both
> >controllers enabled has been tested to work properly (using a custom
> >device tree).
> >See docs/system/devices/can.rst for an example of QEMU command line
> >invocation.
> >
> >More information about the implementation can be found in my bachelor
> >thesis [1].
> >
> >The headers (struct FlexcanRegs and flexcan_regs.h macros) were copied
> >from the Linux kernel. Marc Kleine-Budde is the copyright holder. He
> >has been kindly asked to provide consent, to confirm his approval for
> >the inclusion of said header fragments into QEMU. The approval is still
> >pending, hopefully it will be resolved soon. I will update the patchset
> >on request if another wording/solution for the copyright statement is
> >proposed/requested.
>
> Tested with imx8mp-evk: https://github.com/shentok/qemu/commits/imx8mp-flexcan/ which works excellent. Next step after this series is merged would be upstreaming that branch.
>
> I guess the only open issue is the licensing of struct FlexcanRegs [1] which originates from Linux? How do we proceed here?
>
> Best regards,
> Bernhard
>
> [1] https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.cz/

Could you say what the problem is? In general there is no problem
with taking header structs from the Linux kernel, as they are
GPL-2-only and that is a QEMU-compatible license. The relevant
source files or pieces of source files would need to be noted
as 2-only rather than our default of 2-or-later, but that is
doable -- we already do that for other things we have borrowed
from the kernel.

thanks
-- PMM

Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Tue, 5 May 2026 at 19:03, Bernhard Beschow <shentey@gmail.com> wrote:
>>
>>
>>
>> Am 30. April 2026 18:26:02 UTC schrieb "Matyáš Bobek" <matyas.bobek@gmail.com>:
>> >This series adds emulation of the FlexCAN CAN controller, version 2,
>> >found in NXP i.MX6 series SoCs. The controller is integrated into
>> >fsl-imx6 and the Sabrelite ARM board.
>> >
>> >The chip has two FlexCAN controllers, but the Linux Sabrelite
>> >device tree enables only one by default. Linux kernel with both
>> >controllers enabled has been tested to work properly (using a custom
>> >device tree).
>> >See docs/system/devices/can.rst for an example of QEMU command line
>> >invocation.
>> >
>> >More information about the implementation can be found in my bachelor
>> >thesis [1].
>> >
>> >The headers (struct FlexcanRegs and flexcan_regs.h macros) were copied
>> >from the Linux kernel. Marc Kleine-Budde is the copyright holder. He
>> >has been kindly asked to provide consent, to confirm his approval for
>> >the inclusion of said header fragments into QEMU. The approval is still
>> >pending, hopefully it will be resolved soon. I will update the patchset
>> >on request if another wording/solution for the copyright statement is
>> >proposed/requested.
>>
>> Tested with imx8mp-evk: https://github.com/shentok/qemu/commits/imx8mp-flexcan/ which works excellent. Next step after this series is merged would be upstreaming that branch.
>>
>> I guess the only open issue is the licensing of struct FlexcanRegs [1] which originates from Linux? How do we proceed here?
>>
>> Best regards,
>> Bernhard
>>
>> [1] https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.cz/
>
>Could you say what the problem is? In general there is no problem
>with taking header structs from the Linux kernel, as they are
>GPL-2-only and that is a QEMU-compatible license. The relevant
>source files or pieces of source files would need to be noted
>as 2-only rather than our default of 2-or-later, but that is
>doable -- we already do that for other things we have borrowed
>from the kernel.

In https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@gmail.com/ I raised this review question: "The following structure looks like being based on Linux. Does this affect the copyright of this file?" I was just asking for advice and I'm glad the solution is that easy.

Best regards,
Bernhard

On Tue, 5 May 2026 at 21:21, Bernhard Beschow <shentey@gmail.com> wrote:
> Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >On Tue, 5 May 2026 at 19:03, Bernhard Beschow <shentey@gmail.com> wrote:
> >> I guess the only open issue is the licensing of struct FlexcanRegs [1] which originates from Linux? How do we proceed here?
> >>
> >> Best regards,
> >> Bernhard
> >>
> >> [1] https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.cz/
> >
> >Could you say what the problem is? In general there is no problem
> >with taking header structs from the Linux kernel, as they are
> >GPL-2-only and that is a QEMU-compatible license. The relevant
> >source files or pieces of source files would need to be noted
> >as 2-only rather than our default of 2-or-later, but that is
> >doable -- we already do that for other things we have borrowed
> >from the kernel.
>
> In https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@gmail.com/ I raised this review question: "The following structure looks like being based on Linux. Does this affect the copyright of this file?" I was just asking for advice and I'm glad the solution is that easy.

If the struct was copied from the kernel, then it's GPL-2.0-only,
and we should just note the license and where we got the code from.

If the struct is just very similar to the kernel's one because
it's the obvious representation taken from the datasheet, then
it's not related to the kernel code and we can treat it as
GPL-2.0-or-later like the rest of the file.

Since Matyáš says in the cover letter here "the headers (struct
FlexcanRegs and flexcan_regs.h macros) were copied from the Linux
kernel" then we're in case 1.

You can mark this up by having the file's SPDX tag be
"SPDX-License-Identifier: (GPL-2.0-only AND GPL-2.0-or-later)"
Then have a normal comment in the file next to the part that is
2.0-only that says
/*
 * [This struct / the macros X, Y, Z / whatever ] are borrowed
 * from the Linux kernel, and so (unlike the rest of this file)
 * they are GPL-2.0-only.
 */

thanks
-- PMM

Am 8. Mai 2026 12:10:21 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>On Tue, 5 May 2026 at 21:21, Bernhard Beschow <shentey@gmail.com> wrote:
>> Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
>> >On Tue, 5 May 2026 at 19:03, Bernhard Beschow <shentey@gmail.com> wrote:
>> >> I guess the only open issue is the licensing of struct FlexcanRegs [1] which originates from Linux? How do we proceed here?
>> >>
>> >> Best regards,
>> >> Bernhard
>> >>
>> >> [1] https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.cz/
>> >
>> >Could you say what the problem is? In general there is no problem
>> >with taking header structs from the Linux kernel, as they are
>> >GPL-2-only and that is a QEMU-compatible license. The relevant
>> >source files or pieces of source files would need to be noted
>> >as 2-only rather than our default of 2-or-later, but that is
>> >doable -- we already do that for other things we have borrowed
>> >from the kernel.
>>
>> In https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@gmail.com/ I raised this review question: "The following structure looks like being based on Linux. Does this affect the copyright of this file?" I was just asking for advice and I'm glad the solution is that easy.
>
>If the struct was copied from the kernel, then it's GPL-2.0-only,
>and we should just note the license and where we got the code from.
>
>If the struct is just very similar to the kernel's one because
>it's the obvious representation taken from the datasheet, then
>it's not related to the kernel code and we can treat it as
>GPL-2.0-or-later like the rest of the file.
>
>Since Matyáš says in the cover letter here "the headers (struct
>FlexcanRegs and flexcan_regs.h macros) were copied from the Linux
>kernel" then we're in case 1.
>
>You can mark this up by having the file's SPDX tag be
>"SPDX-License-Identifier: (GPL-2.0-only AND GPL-2.0-or-later)"
>Then have a normal comment in the file next to the part that is
>2.0-only that says
>/*
> * [This struct / the macros X, Y, Z / whatever ] are borrowed
> * from the Linux kernel, and so (unlike the rest of this file)
> * they are GPL-2.0-only.
> */

Ping

Any news? With just the license issue remaining, it would be nice to get FlexCAN support into the upcoming release.

>
>thanks
>-- PMM

Hello Marc,

please, provide your opinion, the license for small Linux kernel
headers excepts seems to be the last and only blocker for mainlining.
See the copied code below.

On Wednesday 27 of May 2026 12:42:23 Bernhard Beschow wrote:
> Am 8. Mai 2026 12:10:21 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >On Tue, 5 May 2026 at 21:21, Bernhard Beschow <shentey@gmail.com> wrote:
> >> Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> >> >On Tue, 5 May 2026 at 19:03, Bernhard Beschow <shentey@gmail.com> wrote:
> >> >> I guess the only open issue is the licensing of struct FlexcanRegs
> >> >> [1] which originates from Linux? How do we proceed here?
> >> >>
> >> >> Best regards,
> >> >> Bernhard
> >> >>
> >> >> [1]
> >> >> https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.c
> >> >>z/
> >> >
> >> >Could you say what the problem is? In general there is no problem
> >> >with taking header structs from the Linux kernel, as they are
> >> >GPL-2-only and that is a QEMU-compatible license. The relevant
> >> >source files or pieces of source files would need to be noted
> >> >as 2-only rather than our default of 2-or-later, but that is
> >> >doable -- we already do that for other things we have borrowed
> >> >from the kernel.
> >>
> >> In
> >> https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@
> >>gmail.com/ I raised this review question: "The following structure looks
> >> like being based on Linux. Does this affect the copyright of this file?"
> >> I was just asking for advice and I'm glad the solution is that easy.
> >
> >If the struct was copied from the kernel, then it's GPL-2.0-only,
> >and we should just note the license and where we got the code from.
> >
> >If the struct is just very similar to the kernel's one because
> >it's the obvious representation taken from the datasheet, then
> >it's not related to the kernel code and we can treat it as
> >GPL-2.0-or-later like the rest of the file.
> >
> >Since Matyáš says in the cover letter here "the headers (struct
> >FlexcanRegs and flexcan_regs.h macros) were copied from the Linux
> >kernel" then we're in case 1.
> >
> >You can mark this up by having the file's SPDX tag be
> >"SPDX-License-Identifier: (GPL-2.0-only AND GPL-2.0-or-later)"
> >Then have a normal comment in the file next to the part that is
> >2.0-only that says
> >/*
> > * [This struct / the macros X, Y, Z / whatever ] are borrowed
> > * from the Linux kernel, and so (unlike the rest of this file)
> > * they are GPL-2.0-only.
> > */
>
> Ping
>
> Any news? With just the license issue remaining, it would be nice to get
> FlexCAN support into the upcoming release.

The problem is that QEMU maintainers decided to prefer GPL-2.0-or-later
as the rule for new contributions and Matyas Bobek has reused
next excepts from Linux kernel sources

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/flexcan/flexcan-core.c

which have license

// SPDX-License-Identifier: GPL-2.0
//
// flexcan.c - FLEXCAN CAN controller driver
//
// Copyright (c) 2005-2006 Varma Electronics Oy
// Copyright (c) 2009 Sascha Hauer, Pengutronix
// Copyright (c) 2010-2017 Pengutronix, Marc Kleine-Budde <kernel@pengutronix.de>
// Copyright (c) 2014 David Jander, Protonic Holland
//
// Based on code originally by Andrey Volkov <avolkov@varma-el.com>


I think, personally, that the code excepts are on the edge
of the rules for copyright applications because the lines are direct
transformation of the offests and bit-fields found in the original
FreeScale/NXP manuals so there should be no problem to use them for
QEMU and revwite from scratch for copyright clarity with a little
different naming rules would make only more mess for future updates
to FexCAN 3 etc.

Thanaks in advance

Pavel

hw/net/can/flexcan_regs.h

+/**
+ * These macros ware originally written for the Linux kernel
+ * by Marc Kleine-Budde.
+ */
+
+/* FLEXCAN module configuration register (CANMCR) bits */
+#define FLEXCAN_MCR_MDIS                BIT(31)
+#define FLEXCAN_MCR_FRZ                 BIT(30)
+#define FLEXCAN_MCR_FEN                 BIT(29)
+#define FLEXCAN_MCR_HALT                BIT(28)
+#define FLEXCAN_MCR_NOT_RDY             BIT(27)
+#define FLEXCAN_MCR_WAK_MSK             BIT(26)
+#define FLEXCAN_MCR_SOFTRST             BIT(25)
+#define FLEXCAN_MCR_FRZ_ACK             BIT(24)
+#define FLEXCAN_MCR_SUPV                BIT(23)
+#define FLEXCAN_MCR_SLF_WAK             BIT(22)
+#define FLEXCAN_MCR_WRN_EN              BIT(21)
+#define FLEXCAN_MCR_LPM_ACK             BIT(20)
+#define FLEXCAN_MCR_WAK_SRC             BIT(19)
+#define FLEXCAN_MCR_DOZE                BIT(18)
+#define FLEXCAN_MCR_SRX_DIS             BIT(17)
+#define FLEXCAN_MCR_IRMQ                BIT(16)
+#define FLEXCAN_MCR_LPRIO_EN            BIT(13)
+#define FLEXCAN_MCR_AEN                 BIT(12)
+#define FLEXCAN_MCR_FDEN                BIT(11)
+#define FLEXCAN_MCR_MAXMB(x)            ((x) & 0x7f)
+#define FLEXCAN_MCR_IDAM_A              (0x0 << 8)
+#define FLEXCAN_MCR_IDAM_B              (0x1 << 8)
+#define FLEXCAN_MCR_IDAM_C              (0x2 << 8)
+#define FLEXCAN_MCR_IDAM_D              (0x3 << 8)
+#define FLEXCAN_MCR_IDAM_MASK           (0x3 << 8)
+
+/* FLEXCAN control register (CANCTRL) bits */
+#define FLEXCAN_CTRL_PRESDIV(x)         (((x) & 0xFF) << 24)
+#define FLEXCAN_CTRL_PRESDIV_MASK       FLEXCAN_CTRL_PRESDIV(UINT32_MAX)
+#define FLEXCAN_CTRL_RJW(x)             (((x) & 0x03) << 22)
+#define FLEXCAN_CTRL_RJW_MASK           FLEXCAN_CTRL_RJW(UINT32_MAX)
+#define FLEXCAN_CTRL_PSEG1(x)           (((x) & 0x07) << 19)
+#define FLEXCAN_CTRL_PSEG1_MASK         FLEXCAN_CTRL_PSEG1(UINT32_MAX)
+#define FLEXCAN_CTRL_PSEG2(x)           (((x) & 0x07) << 16)
+#define FLEXCAN_CTRL_PSEG2_MASK         FLEXCAN_CTRL_PSEG2(UINT32_MAX)
+#define FLEXCAN_CTRL_BOFF_MSK           BIT(15)
+#define FLEXCAN_CTRL_ERR_MSK            BIT(14)
+#define FLEXCAN_CTRL_CLK_SRC            BIT(13)
+#define FLEXCAN_CTRL_LPB                BIT(12)
+#define FLEXCAN_CTRL_TWRN_MSK           BIT(11)
+#define FLEXCAN_CTRL_RWRN_MSK           BIT(10)
+#define FLEXCAN_CTRL_SMP                BIT(7)
+#define FLEXCAN_CTRL_BOFF_REC           BIT(6)
+#define FLEXCAN_CTRL_TSYN               BIT(5)
+#define FLEXCAN_CTRL_LBUF               BIT(4)
+#define FLEXCAN_CTRL_LOM                BIT(3)
+#define FLEXCAN_CTRL_PROPSEG(x)         ((x) & 0x07)
+#define FLEXCAN_CTRL_PROPSEG_MASK       FLEXCAN_CTRL_PROPSEG(UINT32_MAX)
+#define FLEXCAN_CTRL_ERR_BUS            (FLEXCAN_CTRL_ERR_MSK)
+#define FLEXCAN_CTRL_ERR_STATE \
+        (FLEXCAN_CTRL_TWRN_MSK | FLEXCAN_CTRL_RWRN_MSK | \
+         FLEXCAN_CTRL_BOFF_MSK)
+#define FLEXCAN_CTRL_ERR_ALL \
+        (FLEXCAN_CTRL_ERR_BUS | FLEXCAN_CTRL_ERR_STATE)
+
+/* FLEXCAN control register 2 (CTRL2) bits */
+#define FLEXCAN_CTRL2_ECRWRE            BIT(29)
+#define FLEXCAN_CTRL2_WRMFRZ            BIT(28)
+#define FLEXCAN_CTRL2_RFFN(x)           (((x) & 0x0f) << 24)
+#define FLEXCAN_CTRL2_TASD(x)           (((x) & 0x1f) << 19)
+#define FLEXCAN_CTRL2_MRP               BIT(18)
+#define FLEXCAN_CTRL2_RRS               BIT(17)
+#define FLEXCAN_CTRL2_EACEN             BIT(16)
+#define FLEXCAN_CTRL2_ISOCANFDEN        BIT(12)
+
+/* FLEXCAN memory error control register (MECR) bits */
+#define FLEXCAN_MECR_ECRWRDIS           BIT(31)
+#define FLEXCAN_MECR_HANCEI_MSK         BIT(19)
+#define FLEXCAN_MECR_FANCEI_MSK         BIT(18)
+#define FLEXCAN_MECR_CEI_MSK            BIT(16)
+#define FLEXCAN_MECR_HAERRIE            BIT(15)
+#define FLEXCAN_MECR_FAERRIE            BIT(14)
+#define FLEXCAN_MECR_EXTERRIE           BIT(13)
+#define FLEXCAN_MECR_RERRDIS            BIT(9)
+#define FLEXCAN_MECR_ECCDIS             BIT(8)
+#define FLEXCAN_MECR_NCEFAFRZ           BIT(7)
+
+/* FLEXCAN error and status register (ESR) bits */
+#define FLEXCAN_ESR_SYNCH               BIT(18)
+#define FLEXCAN_ESR_TWRN_INT            BIT(17)
+#define FLEXCAN_ESR_RWRN_INT            BIT(16)
+#define FLEXCAN_ESR_BIT1_ERR            BIT(15)
+#define FLEXCAN_ESR_BIT0_ERR            BIT(14)
+#define FLEXCAN_ESR_ACK_ERR             BIT(13)
+#define FLEXCAN_ESR_CRC_ERR             BIT(12)
+#define FLEXCAN_ESR_FRM_ERR             BIT(11)
+#define FLEXCAN_ESR_STF_ERR             BIT(10)
+#define FLEXCAN_ESR_TX_WRN              BIT(9)
+#define FLEXCAN_ESR_RX_WRN              BIT(8)
+#define FLEXCAN_ESR_IDLE                BIT(7)
+#define FLEXCAN_ESR_BOFF_INT            BIT(2)
+#define FLEXCAN_ESR_ERR_INT             BIT(1)
+#define FLEXCAN_ESR_WAK_INT             BIT(0)
+
+/* FLEXCAN Bit Timing register (CBT) bits */
+#define FLEXCAN_CBT_BTF                 BIT(31)
+#define FLEXCAN_CBT_EPRESDIV_MASK       FLEXCAN_GENMASK(30, 21)
+#define FLEXCAN_CBT_ERJW_MASK           FLEXCAN_GENMASK(20, 16)
+#define FLEXCAN_CBT_EPROPSEG_MASK       FLEXCAN_GENMASK(15, 10)
+#define FLEXCAN_CBT_EPSEG1_MASK         FLEXCAN_GENMASK(9, 5)
+#define FLEXCAN_CBT_EPSEG2_MASK         FLEXCAN_GENMASK(4, 0)
+
+/* FLEXCAN FD control register (FDCTRL) bits */
+#define FLEXCAN_FDCTRL_FDRATE           BIT(31)
+#define FLEXCAN_FDCTRL_MBDSR1           FLEXCAN_GENMASK(20, 19)
+#define FLEXCAN_FDCTRL_MBDSR0           FLEXCAN_GENMASK(17, 16)
+#define FLEXCAN_FDCTRL_MBDSR_8          0x0
+#define FLEXCAN_FDCTRL_MBDSR_12         0x1
+#define FLEXCAN_FDCTRL_MBDSR_32         0x2
+#define FLEXCAN_FDCTRL_MBDSR_64         0x3
+#define FLEXCAN_FDCTRL_TDCEN            BIT(15)
+#define FLEXCAN_FDCTRL_TDCFAIL          BIT(14)
+#define FLEXCAN_FDCTRL_TDCOFF           FLEXCAN_GENMASK(12, 8)
+#define FLEXCAN_FDCTRL_TDCVAL           FLEXCAN_GENMASK(5, 0)
+
+/* FLEXCAN FD Bit Timing register (FDCBT) bits */
+#define FLEXCAN_FDCBT_FPRESDIV_MASK     FLEXCAN_GENMASK(29, 20)
+#define FLEXCAN_FDCBT_FRJW_MASK         FLEXCAN_GENMASK(18, 16)
+#define FLEXCAN_FDCBT_FPROPSEG_MASK     FLEXCAN_GENMASK(14, 10)
+#define FLEXCAN_FDCBT_FPSEG1_MASK       FLEXCAN_GENMASK(7, 5)
+#define FLEXCAN_FDCBT_FPSEG2_MASK       FLEXCAN_GENMASK(2, 0)
+
+/* FLEXCAN CRC Register (CRCR) bits */
+#define FLEXCAN_CRCR_MBCRC_MASK         FLEXCAN_GENMASK(22, 16)
+#define FLEXCAN_CRCR_MBCRC(x)           (((x) & FLEXCAN_CRCR_MBCRC_MASK) << 16)
+#define FLEXCAN_CRCR_TXCRC_MASK         FLEXCAN_GENMASK(14, 0)
+#define FLEXCAN_CRCR_TXCRC(x)           ((x) & FLEXCAN_CRCR_TXCRC_MASK)
+
+/* FLEXCAN interrupt flag register (IFLAG) bits */
+/* Errata ERR005829 step7: Reserve first valid MB */
+#define I_FIFO_OVERFLOW  7
+#define I_FIFO_WARN      6
+#define I_FIFO_AVAILABLE 5
+
+#define FLEXCAN_TX_MB_RESERVED_RX_FIFO  8
+#define FLEXCAN_TX_MB_RESERVED_RX_MAILBOX       0
+#define FLEXCAN_RX_MB_RX_MAILBOX_FIRST  (FLEXCAN_TX_MB_RESERVED_RX_MAILBOX + 1)
+#define FLEXCAN_IFLAG_MB(x)             BIT_ULL(x)
+#define FLEXCAN_IFLAG_RX_FIFO_OVERFLOW  BIT(I_FIFO_OVERFLOW)
+#define FLEXCAN_IFLAG_RX_FIFO_WARN      BIT(I_FIFO_WARN)
+#define FLEXCAN_IFLAG_RX_FIFO_AVAILABLE BIT(I_FIFO_AVAILABLE)
+
+/* FLEXCAN message buffers */
+#define FLEXCAN_MB_CODE_RX_BUSY_BIT     (0x1 << 24)
+#define FLEXCAN_MB_CODE_RX_INACTIVE     (0x0 << 24)
+#define FLEXCAN_MB_CODE_RX_EMPTY        (0x4 << 24)
+#define FLEXCAN_MB_CODE_RX_FULL         (0x2 << 24)
+#define FLEXCAN_MB_CODE_RX_OVERRUN      (0x6 << 24)
+#define FLEXCAN_MB_CODE_RX_RANSWER      (0xa << 24)
+
+#define FLEXCAN_MB_CODE_TX_INACTIVE     (0x8 << 24)
+#define FLEXCAN_MB_CODE_TX_ABORT        (0x9 << 24)
+#define FLEXCAN_MB_CODE_TX_DATA         (0xc << 24)
+#define FLEXCAN_MB_CODE_TX_TANSWER      (0xe << 24)
+
+#define FLEXCAN_MB_CODE(x)              (((x) & 0xF) << 24)
+#define FLEXCAN_MB_CODE_MASK            FLEXCAN_MB_CODE(UINT32_MAX)
+
+#define FLEXCAN_MB_CNT_EDL              BIT(31)
+#define FLEXCAN_MB_CNT_BRS              BIT(30)
+#define FLEXCAN_MB_CNT_ESI              BIT(29)
+#define FLEXCAN_MB_CNT_SRR              BIT(22)
+#define FLEXCAN_MB_CNT_IDE              BIT(21)
+#define FLEXCAN_MB_CNT_RTR              BIT(20)
+#define FLEXCAN_MB_CNT_LENGTH(x)        (((x) & 0xF) << 16)
+#define FLEXCAN_MB_CNT_TIMESTAMP(x)     ((x) & 0xFFFF)
+#define FLEXCAN_MB_CNT_TIMESTAMP_MASK   FLEXCAN_MB_CNT_TIMESTAMP(UINT32_MAX)

+/* view of single message buffer registers */
+typedef struct FlexcanRegsMessageBuffer {
+    uint32_t can_ctrl;
+    uint32_t can_id;
+    uint32_t data[2];
+} FlexcanRegsMessageBuffer;


include/hw/net/flexcan.h

+/**
+ * Structure of the hardware registers
+ *
+ * originally created for the Linux kernel by Marc Kleine-Budde
+ */
+typedef struct FlexcanRegs {
+    uint32_t mcr;                /* 0x00 */
+    uint32_t ctrl;               /* 0x04 - not affected by soft reset */
+    uint32_t timer;              /* 0x08 */
+    uint32_t tcr;                /* 0x0C */
+    uint32_t rxmgmask;           /* 0x10 - not affected by soft reset */
+    uint32_t rx14mask;           /* 0x14 - not affected by soft reset */
+    uint32_t rx15mask;           /* 0x18 - not affected by soft reset */
+    uint32_t ecr;                /* 0x1C */
+    uint32_t esr;                /* 0x20 */
+    uint32_t imask2;             /* 0x24 */
+    uint32_t imask1;             /* 0x28 */
+    uint32_t iflag2;             /* 0x2C */
+    uint32_t iflag1;             /* 0x30 */
+    union {                      /* 0x34 */
+        uint32_t gfwr_mx28;      /* MX28, MX53 */
+        uint32_t ctrl2;          /* MX6, VF610 - not affected by soft reset */
+    };
+    uint32_t esr2;               /* 0x38 */
+    uint32_t imeur;              /* 0x3C, unused */
+    uint32_t lrfr;               /* 0x40, unused */
+    uint32_t crcr;               /* 0x44 */
+    uint32_t rxfgmask;           /* 0x48 */
+    uint32_t rxfir;              /* 0x4C - not affected by soft reset */
+    uint32_t cbt;                /* 0x50, unused - not affected by soft reset */
+    uint32_t _reserved2;         /* 0x54 */
+    uint32_t dbg1;               /* 0x58, unused */
+    uint32_t dbg2;               /* 0x5C, unused */
+    uint32_t _reserved3[8];      /* 0x60 */
+    union {                      /* 0x80 - not affected by soft reset */
+        uint32_t mb[sizeof(FlexcanRegsMessageBuffer) * FLEXCAN_MAILBOX_COUNT];
+        FlexcanRegsMessageBuffer mbs[FLEXCAN_MAILBOX_COUNT];
+        FlexcanRegsRXFifo fifo;
+    };
+    uint32_t _reserved4[256];    /* 0x480 */
+    uint32_t rximr[64];          /* 0x880 - not affected by soft reset */
+    uint32_t _reserved5[24];     /* 0x980 */
+    uint32_t gfwr_mx6;           /* 0x9E0 - MX6 */
+
+    /* the rest is unused except for SMB */
+    uint32_t _reserved6[39];     /* 0x9E4 */
+    uint32_t _rxfir[6];          /* 0xA80 */
+    uint32_t _reserved8[2];      /* 0xA98 */
+    uint32_t _rxmgmask;          /* 0xAA0 */
+    uint32_t _rxfgmask;          /* 0xAA4 */
+    uint32_t _rx14mask;          /* 0xAA8 */
+    uint32_t _rx15mask;          /* 0xAAC */
+    uint32_t tx_smb[4];          /* 0xAB0 */
+    union {                      /* 0xAC0, used for SMB emulation */
+        uint32_t rx_smb0_raw[4];
+        FlexcanRegsMessageBuffer rx_smb0;
+    };
+    uint32_t rx_smb1[4];         /* 0xAD0 */
+    uint32_t mecr;               /* 0xAE0 */
+    uint32_t erriar;             /* 0xAE4 */
+    uint32_t erridpr;            /* 0xAE8 */
+    uint32_t errippr;            /* 0xAEC */
+    uint32_t rerrar;             /* 0xAF0 */
+    uint32_t rerrdr;             /* 0xAF4 */
+    uint32_t rerrsynr;           /* 0xAF8 */
+    uint32_t errsr;              /* 0xAFC */
+    uint32_t _reserved7[64];     /* 0xB00 */
+    uint32_t fdctrl;             /* 0xC00 - not affected by soft reset */
+    uint32_t fdcbt;              /* 0xC04 - not affected by soft reset */
+    uint32_t fdcrc;              /* 0xC08 */
+    uint32_t _reserved9[199];    /* 0xC0C */
+    uint32_t tx_smb_fd[18];      /* 0xF28 */
+    uint32_t rx_smb0_fd[18];     /* 0xF70 */
+    uint32_t rx_smb1_fd[18];     /* 0xFB8 */
+} FlexcanRegs;
+

Hello,

On 27.05.2026 17:38:21, Pavel Pisa wrote:
> please, provide your opinion, the license for small Linux kernel
> headers excepts seems to be the last and only blocker for mainlining.
> See the copied code below.

not sure how much help I can provide...

> On Wednesday 27 of May 2026 12:42:23 Bernhard Beschow wrote:
> > Am 8. Mai 2026 12:10:21 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> > >On Tue, 5 May 2026 at 21:21, Bernhard Beschow <shentey@gmail.com> wrote:
> > >> Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell <peter.maydell@linaro.org>:
> > >> >On Tue, 5 May 2026 at 19:03, Bernhard Beschow <shentey@gmail.com> wrote:
> > >> >> I guess the only open issue is the licensing of struct FlexcanRegs
> > >> >> [1] which originates from Linux? How do we proceed here?
> > >> >>
> > >> >> Best regards,
> > >> >> Bernhard
> > >> >>
> > >> >> [1]
> > >> >> https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.c
> > >> >>z/
> > >> >
> > >> >Could you say what the problem is? In general there is no problem
> > >> >with taking header structs from the Linux kernel, as they are
> > >> >GPL-2-only and that is a QEMU-compatible license. The relevant
> > >> >source files or pieces of source files would need to be noted
> > >> >as 2-only rather than our default of 2-or-later, but that is
> > >> >doable -- we already do that for other things we have borrowed
> > >> >from the kernel.

This would be IMHO the cleared solution. Put these macros into a
separate file with the proper license and copyright headers copied from
the kernel driver.

> > >> In
> > >> https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@
> > >>gmail.com/ I raised this review question: "The following structure looks
> > >> like being based on Linux. Does this affect the copyright of this file?"
> > >> I was just asking for advice and I'm glad the solution is that easy.
> > >
> > >If the struct was copied from the kernel, then it's GPL-2.0-only,
> > >and we should just note the license and where we got the code from.
> > >
> > >If the struct is just very similar to the kernel's one because
> > >it's the obvious representation taken from the datasheet, then
> > >it's not related to the kernel code and we can treat it as
> > >GPL-2.0-or-later like the rest of the file.
> > >
> > >Since Matyáš says in the cover letter here "the headers (struct
> > >FlexcanRegs and flexcan_regs.h macros) were copied from the Linux
> > >kernel" then we're in case 1.
> > >
> > >You can mark this up by having the file's SPDX tag be
> > >"SPDX-License-Identifier: (GPL-2.0-only AND GPL-2.0-or-later)"
> > >Then have a normal comment in the file next to the part that is
> > >2.0-only that says
> > >/*
> > > * [This struct / the macros X, Y, Z / whatever ] are borrowed
> > > * from the Linux kernel, and so (unlike the rest of this file)
> > > * they are GPL-2.0-only.
> > > */
> >
> > Ping
> >
> > Any news? With just the license issue remaining, it would be nice to get
> > FlexCAN support into the upcoming release.
>
> The problem is that QEMU maintainers decided to prefer GPL-2.0-or-later
> as the rule for new contributions and Matyas Bobek has reused
> next excepts from Linux kernel sources
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/flexcan/flexcan-core.c
>
> which have license
>
> // SPDX-License-Identifier: GPL-2.0
> //
> // flexcan.c - FLEXCAN CAN controller driver
> //
> // Copyright (c) 2005-2006 Varma Electronics Oy
> // Copyright (c) 2009 Sascha Hauer, Pengutronix
> // Copyright (c) 2010-2017 Pengutronix, Marc Kleine-Budde <kernel@pengutronix.de>
> // Copyright (c) 2014 David Jander, Protonic Holland
> //
> // Based on code originally by Andrey Volkov <avolkov@varma-el.com>
>
>
> I think, personally, that the code excepts are on the edge
> of the rules for copyright applications because the lines are direct
> transformation of the offests and bit-fields found in the original
> FreeScale/NXP manuals so there should be no problem to use them for
> QEMU and revwite from scratch for copyright clarity with a little
> different naming rules would make only more mess for future updates
> to FexCAN 3 etc.

As you target currently imx6 only, you can re-create them from the imx6
data sheet, it already comes with "C" compatible naming scheme, e.g.:

| "Rx Mailboxes Global Mask Register (FLEXCAN1_RXMGMASK)"

> hw/net/can/flexcan_regs.h
>
> +/**
> + * These macros ware originally written for the Linux kernel
> + * by Marc Kleine-Budde.
> + */

This is not 100% correct. I'm the git-author of the initial mainline
flexcan commit e955cead0311 ("CAN: Add Flexcan CAN controller driver"),
but it already comes with these copyright statements:

+ * Copyright (c) 2005-2006 Varma Electronics Oy
+ * Copyright (c) 2009 Sascha Hauer, Pengutronix
+ * Copyright (c) 2010 Marc Kleine-Budde, Pengutronix
+ *
+ * Based on code originally by Andrey Volkov <avolkov@varma-el.com>

So I cannot re-license even the initial file alone, Sascha is my
co-worker.

Hope that helps,
Marc

--
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Hello Pavel, Marc,

As the original author, I have no objection to reusing (my part of) the 
header under GPL-2.0-or-later. The reason it was not done that way in 
2005/2006 is simple: only GPLv2 existed at the time.

All the more so since, as already noted, the code in question is 
essentially a direct transcription of offsets and bit-fields from the 
Freescale/NXP datasheets, which leaves very little room for a meaningful 
copyright claim in the first place.

Personally, I would prefer that this code not be rewritten and be kept 
as is, to avoid introducing subtle bugs in QEMU later on.
That said, @Sascha and @David may have a different opinion.

PS: andrey.volkov@munic.io is my correct current work address, but I 
would prefer to use my personal one for this discussion.

Regards,
Andrey Volkov

Le 27/05/2026 à 18:09, Marc Kleine-Budde a écrit :
> Hello,
>
> On 27.05.2026 17:38:21, Pavel Pisa wrote:
>> please, provide your opinion, the license for small Linux kernel
>> headers excepts seems to be the last and only blocker for mainlining.
>> See the copied code below.
> not sure how much help I can provide...
>
>> On Wednesday 27 of May 2026 12:42:23 Bernhard Beschow wrote:
>>> Am 8. Mai 2026 12:10:21 UTC schrieb Peter Maydell<peter.maydell@linaro.org>:
>>>> On Tue, 5 May 2026 at 21:21, Bernhard Beschow<shentey@gmail.com> wrote:
>>>>> Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell<peter.maydell@linaro.org>:
>>>>>> On Tue, 5 May 2026 at 19:03, Bernhard Beschow<shentey@gmail.com> wrote:
>>>>>>> I guess the only open issue is the licensing of struct FlexcanRegs
>>>>>>> [1] which originates from Linux? How do we proceed here?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Bernhard
>>>>>>>
>>>>>>> [1]
>>>>>>> https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.c
>>>>>>> z/
>>>>>> Could you say what the problem is? In general there is no problem
>>>>>> with taking header structs from the Linux kernel, as they are
>>>>>> GPL-2-only and that is a QEMU-compatible license. The relevant
>>>>>> source files or pieces of source files would need to be noted
>>>>>> as 2-only rather than our default of 2-or-later, but that is
>>>>>> doable -- we already do that for other things we have borrowed
>>>>> >from the kernel.
> This would be IMHO the cleared solution. Put these macros into a
> separate file with the proper license and copyright headers copied from
> the kernel driver.
>
>>>>> In
>>>>> https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@
>>>>> gmail.com/ I raised this review question: "The following structure looks
>>>>> like being based on Linux. Does this affect the copyright of this file?"
>>>>> I was just asking for advice and I'm glad the solution is that easy.
>>>> If the struct was copied from the kernel, then it's GPL-2.0-only,
>>>> and we should just note the license and where we got the code from.
>>>>
>>>> If the struct is just very similar to the kernel's one because
>>>> it's the obvious representation taken from the datasheet, then
>>>> it's not related to the kernel code and we can treat it as
>>>> GPL-2.0-or-later like the rest of the file.
>>>>
>>>> Since Matyáš says in the cover letter here "the headers (struct
>>>> FlexcanRegs and flexcan_regs.h macros) were copied from the Linux
>>>> kernel" then we're in case 1.
>>>>
>>>> You can mark this up by having the file's SPDX tag be
>>>> "SPDX-License-Identifier: (GPL-2.0-only AND GPL-2.0-or-later)"
>>>> Then have a normal comment in the file next to the part that is
>>>> 2.0-only that says
>>>> /*
>>>> * [This struct / the macros X, Y, Z / whatever ] are borrowed
>>>> * from the Linux kernel, and so (unlike the rest of this file)
>>>> * they are GPL-2.0-only.
>>>> */
>>> Ping
>>>
>>> Any news? With just the license issue remaining, it would be nice to get
>>> FlexCAN support into the upcoming release.
>> The problem is that QEMU maintainers decided to prefer GPL-2.0-or-later
>> as the rule for new contributions and Matyas Bobek has reused
>> next excepts from Linux kernel sources
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/flexcan/flexcan-core.c
>>
>> which have license
>>
>> // SPDX-License-Identifier: GPL-2.0
>> //
>> // flexcan.c - FLEXCAN CAN controller driver
>> //
>> // Copyright (c) 2005-2006 Varma Electronics Oy
>> // Copyright (c) 2009 Sascha Hauer, Pengutronix
>> // Copyright (c) 2010-2017 Pengutronix, Marc Kleine-Budde<kernel@pengutronix.de>
>> // Copyright (c) 2014 David Jander, Protonic Holland
>> //
>> // Based on code originally by Andrey Volkov<avolkov@varma-el.com>
>>
>>
>> I think, personally, that the code excepts are on the edge
>> of the rules for copyright applications because the lines are direct
>> transformation of the offests and bit-fields found in the original
>> FreeScale/NXP manuals so there should be no problem to use them for
>> QEMU and revwite from scratch for copyright clarity with a little
>> different naming rules would make only more mess for future updates
>> to FexCAN 3 etc.
> As you target currently imx6 only, you can re-create them from the imx6
> data sheet, it already comes with "C" compatible naming scheme, e.g.:
>
> | "Rx Mailboxes Global Mask Register (FLEXCAN1_RXMGMASK)"
>
>> hw/net/can/flexcan_regs.h
>>
>> +/**
>> + * These macros ware originally written for the Linux kernel
>> + * by Marc Kleine-Budde.
>> + */
> This is not 100% correct. I'm the git-author of the initial mainline
> flexcan commit e955cead0311 ("CAN: Add Flexcan CAN controller driver"),
> but it already comes with these copyright statements:
>
> + * Copyright (c) 2005-2006 Varma Electronics Oy
> + * Copyright (c) 2009 Sascha Hauer, Pengutronix
> + * Copyright (c) 2010 Marc Kleine-Budde, Pengutronix
> + *
> + * Based on code originally by Andrey Volkov<avolkov@varma-el.com>
>
> So I cannot re-license even the initial file alone, Sascha is my
> co-worker.
>
> Hope that helps,
> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde          |
> Embedded Linux                   |https://www.pengutronix.de |
> Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |
-- 

*Andrei VOLKOV — MUNIC CAR DATA
*Senior Software Engineer**

https://www.munic.io

39 avenue de Paris, 94800 Villejuif — France

tel: +33 (0) 1 42 11 93 25

On 27.05.2026 18:25:37, Andrei VOLKOV wrote:
> As the original author, I have no objection to reusing (my part of) the
> header under GPL-2.0-or-later. The reason it was not done that way in
> 2005/2006 is simple: only GPLv2 existed at the time.
>
> All the more so since, as already noted, the code in question is essentially
> a direct transcription of offsets and bit-fields from the Freescale/NXP
> datasheets, which leaves very little room for a meaningful copyright claim
> in the first place.
>
> Personally, I would prefer that this code not be rewritten and be kept as
> is, to avoid introducing subtle bugs in QEMU later on.
> That said, @Sascha and @David may have a different opinion.
>
> PS: andrey.volkov@munic.io is my correct current work address, but I would
> prefer to use my personal one for this discussion.

I've added David on Cc and given them a short overview of this
discussion and linked this thread.

I'll agree to re-license the register definitions of the flexcan driver
to GPL-2.0-or-later. I'll poke Sasha tomorrow.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

On Wed, 27 May 2026 20:38:10 +0200
Marc Kleine-Budde <mkl@pengutronix.de> wrote:

> On 27.05.2026 18:25:37, Andrei VOLKOV wrote:
> > As the original author, I have no objection to reusing (my part of) the
> > header under GPL-2.0-or-later. The reason it was not done that way in
> > 2005/2006 is simple: only GPLv2 existed at the time.
> >
> > All the more so since, as already noted, the code in question is essentially
> > a direct transcription of offsets and bit-fields from the Freescale/NXP
> > datasheets, which leaves very little room for a meaningful copyright claim
> > in the first place.
> >
> > Personally, I would prefer that this code not be rewritten and be kept as
> > is, to avoid introducing subtle bugs in QEMU later on.
> > That said, @Sascha and @David may have a different opinion.
> >
> > PS: andrey.volkov@munic.io is my correct current work address, but I would
> > prefer to use my personal one for this discussion.  
> 
> I've added David on Cc and given them a short overview of this
> discussion and linked this thread.
> 
> I'll agree to re-license the register definitions of the flexcan driver
> to GPL-2.0-or-later. I'll poke Sasha tomorrow.

I have no objections for this part to be used under GPL-2.0-or-later.

Best regards,

-- 
David Jander

On 2026-05-27 20:38, Marc Kleine-Budde wrote:
> On 27.05.2026 18:25:37, Andrei VOLKOV wrote:
> > As the original author, I have no objection to reusing (my part of) the
> > header under GPL-2.0-or-later. The reason it was not done that way in
> > 2005/2006 is simple: only GPLv2 existed at the time.
> >
> > All the more so since, as already noted, the code in question is essentially
> > a direct transcription of offsets and bit-fields from the Freescale/NXP
> > datasheets, which leaves very little room for a meaningful copyright claim
> > in the first place.
> >
> > Personally, I would prefer that this code not be rewritten and be kept as
> > is, to avoid introducing subtle bugs in QEMU later on.
> > That said, @Sascha and @David may have a different opinion.
> >
> > PS: andrey.volkov@munic.io is my correct current work address, but I would
> > prefer to use my personal one for this discussion.
> 
> I've added David on Cc and given them a short overview of this
> discussion and linked this thread.
> 
> I'll agree to re-license the register definitions of the flexcan driver
> to GPL-2.0-or-later. I'll poke Sasha tomorrow.

No objections from me as well.

Sascha

--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Hello All,

On Thursday 28 of May 2026 10:53:42 Sascha Hauer wrote:
> On 2026-05-27 20:38, Marc Kleine-Budde wrote:
> > On 27.05.2026 18:25:37, Andrei VOLKOV wrote:
> > > As the original author, I have no objection to reusing (my part of) the
> > > header under GPL-2.0-or-later. The reason it was not done that way in
> > > 2005/2006 is simple: only GPLv2 existed at the time.

thanks everybody for the approval to reticence
as GPL-2.0 and latter.

To Andrey Volkov, excuse for using inappropriate address,
but the questionable copyright situation has been raised
and was main problem even for the v2 series version from
March and it seems not to move forward from that time
so I have tried to find some address on which you could
respond as the original author and I expect that your
original address at varma-el.com is no longer valid.

I think/remeber that there is no other request for changes
in this round of review. May it be, the additional
authors can be added to the headers code excerpt.

But generally I approve this FlexCAN support
to be merged into QEMU master as CAN subsystem
co-maintainer and I would be happy merge is proceed
by somebody with commit right. Directly, directly
with addition of Andrey Volkov and Sascha Hauer to
the last line of notice in

hw/net/can/flexcan_regs.h

and

include/hw/net/flexcan.h

+/**
+ * These macros ware originally written for the Linux kernel
+ * by Andrey Volkov, Sascha Hauer and Marc Kleine-Budde.
+ */

or Matyas Bobek can modify the line and send
v4 version.

I would be happy if the code is merged, and it can be the base
for some future project to extend support to iMX8
FlexCAN 3. Maybe I can find a student or somebody
provides resources, time, GSoC funding, or some other option
to attract some students to take the opportunity
to work on a project and learn something as a summer job...
There are a lot more interesting controllers to support,
I (with Michal Lenc) lead RTEMS D-CAN driver support
GSoC for AM335x this year, QEMU support would be nice
for CI there, we would continue on the PolarFire driver
for RTEMS, one day, matching QEMU support would help.
Long-term, multiqueue and priority for Linux would be worth
solving; results on CTU CAN FD on RTEMS are exceptional.
There are plenty of opportunities to have fun.

Best wishes,

                Pavel

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    social:     https://social.kernel.org/ppisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

On 27.05.2026 20:38:10, Marc Kleine-Budde wrote:
> I'll agree to re-license the register definitions of the flexcan driver
> to GPL-2.0-or-later. I'll poke Sasha tomorrow.

Typo: Sascha

Sorry,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Le 27/05/2026 à 18:25, Andrei VOLKOV a écrit :
>
> Hello Pavel, Marc,
>
> As the original author, I have no objection to reusing (my part of) 
> the header under GPL-2.0-or-later. The reason it was not done that way 
> in 2005/2006 is simple: only GPLv2 existed at the time.
>
> All the more so since, as already noted, the code in question is 
> essentially a direct transcription of offsets and bit-fields from the 
> Freescale/NXP datasheets, which leaves very little room for a 
> meaningful copyright claim in the first place.
>
> Personally, I would prefer that this code not be rewritten and be kept 
> as is, to avoid introducing subtle bugs in QEMU later on.
> That said, @Sascha and @David may have a different opinion.
>
> PS: andrey.volkov@munic.io is my correct current work address, but I 
> would prefer to use my personal one for this discussion.
>
This one: andrey@volkov.fr

>
> Regards,
> Andrey Volkov
>
> Le 27/05/2026 à 18:09, Marc Kleine-Budde a écrit :
>> Hello,
>>
>> On 27.05.2026 17:38:21, Pavel Pisa wrote:
>>> please, provide your opinion, the license for small Linux kernel
>>> headers excepts seems to be the last and only blocker for mainlining.
>>> See the copied code below.
>> not sure how much help I can provide...
>>
>>> On Wednesday 27 of May 2026 12:42:23 Bernhard Beschow wrote:
>>>> Am 8. Mai 2026 12:10:21 UTC schrieb Peter Maydell<peter.maydell@linaro.org>:
>>>>> On Tue, 5 May 2026 at 21:21, Bernhard Beschow<shentey@gmail.com> wrote:
>>>>>> Am 5. Mai 2026 18:41:52 UTC schrieb Peter Maydell<peter.maydell@linaro.org>:
>>>>>>> On Tue, 5 May 2026 at 19:03, Bernhard Beschow<shentey@gmail.com> wrote:
>>>>>>>> I guess the only open issue is the licensing of struct FlexcanRegs
>>>>>>>> [1] which originates from Linux? How do we proceed here?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Bernhard
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://lore.kernel.org/qemu-devel/202603211316.18181.pisa@fel.cvut.c
>>>>>>>> z/
>>>>>>> Could you say what the problem is? In general there is no problem
>>>>>>> with taking header structs from the Linux kernel, as they are
>>>>>>> GPL-2-only and that is a QEMU-compatible license. The relevant
>>>>>>> source files or pieces of source files would need to be noted
>>>>>>> as 2-only rather than our default of 2-or-later, but that is
>>>>>>> doable -- we already do that for other things we have borrowed
>>>>>> >from the kernel.
>> This would be IMHO the cleared solution. Put these macros into a
>> separate file with the proper license and copyright headers copied from
>> the kernel driver.
>>
>>>>>> In
>>>>>> https://lore.kernel.org/qemu-devel/f3cb3166-c3f8-4ed8-8c9a-cbf48b071d1e@
>>>>>> gmail.com/ I raised this review question: "The following structure looks
>>>>>> like being based on Linux. Does this affect the copyright of this file?"
>>>>>> I was just asking for advice and I'm glad the solution is that easy.
>>>>> If the struct was copied from the kernel, then it's GPL-2.0-only,
>>>>> and we should just note the license and where we got the code from.
>>>>>
>>>>> If the struct is just very similar to the kernel's one because
>>>>> it's the obvious representation taken from the datasheet, then
>>>>> it's not related to the kernel code and we can treat it as
>>>>> GPL-2.0-or-later like the rest of the file.
>>>>>
>>>>> Since Matyáš says in the cover letter here "the headers (struct
>>>>> FlexcanRegs and flexcan_regs.h macros) were copied from the Linux
>>>>> kernel" then we're in case 1.
>>>>>
>>>>> You can mark this up by having the file's SPDX tag be
>>>>> "SPDX-License-Identifier: (GPL-2.0-only AND GPL-2.0-or-later)"
>>>>> Then have a normal comment in the file next to the part that is
>>>>> 2.0-only that says
>>>>> /*
>>>>> * [This struct / the macros X, Y, Z / whatever ] are borrowed
>>>>> * from the Linux kernel, and so (unlike the rest of this file)
>>>>> * they are GPL-2.0-only.
>>>>> */
>>>> Ping
>>>>
>>>> Any news? With just the license issue remaining, it would be nice to get
>>>> FlexCAN support into the upcoming release.
>>> The problem is that QEMU maintainers decided to prefer GPL-2.0-or-later
>>> as the rule for new contributions and Matyas Bobek has reused
>>> next excepts from Linux kernel sources
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/flexcan/flexcan-core.c
>>>
>>> which have license
>>>
>>> // SPDX-License-Identifier: GPL-2.0
>>> //
>>> // flexcan.c - FLEXCAN CAN controller driver
>>> //
>>> // Copyright (c) 2005-2006 Varma Electronics Oy
>>> // Copyright (c) 2009 Sascha Hauer, Pengutronix
>>> // Copyright (c) 2010-2017 Pengutronix, Marc Kleine-Budde<kernel@pengutronix.de>
>>> // Copyright (c) 2014 David Jander, Protonic Holland
>>> //
>>> // Based on code originally by Andrey Volkov<avolkov@varma-el.com>
>>>
>>>
>>> I think, personally, that the code excepts are on the edge
>>> of the rules for copyright applications because the lines are direct
>>> transformation of the offests and bit-fields found in the original
>>> FreeScale/NXP manuals so there should be no problem to use them for
>>> QEMU and revwite from scratch for copyright clarity with a little
>>> different naming rules would make only more mess for future updates
>>> to FexCAN 3 etc.
>> As you target currently imx6 only, you can re-create them from the imx6
>> data sheet, it already comes with "C" compatible naming scheme, e.g.:
>>
>> | "Rx Mailboxes Global Mask Register (FLEXCAN1_RXMGMASK)"
>>
>>> hw/net/can/flexcan_regs.h
>>>
>>> +/**
>>> + * These macros ware originally written for the Linux kernel
>>> + * by Marc Kleine-Budde.
>>> + */
>> This is not 100% correct. I'm the git-author of the initial mainline
>> flexcan commit e955cead0311 ("CAN: Add Flexcan CAN controller driver"),
>> but it already comes with these copyright statements:
>>
>> + * Copyright (c) 2005-2006 Varma Electronics Oy
>> + * Copyright (c) 2009 Sascha Hauer, Pengutronix
>> + * Copyright (c) 2010 Marc Kleine-Budde, Pengutronix
>> + *
>> + * Based on code originally by Andrey Volkov<avolkov@varma-el.com>
>>
>> So I cannot re-license even the initial file alone, Sascha is my
>> co-worker.
>>
>> Hope that helps,
>> Marc
>>
>> --
>> Pengutronix e.K.                 | Marc Kleine-Budde          |
>> Embedded Linux                   |https://www.pengutronix.de |
>> Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
>> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |
> -- 
>
> *Andrei VOLKOV — MUNIC CAR DATA
> *Senior Software Engineer**
>
> https://www.munic.io
>
> 39 avenue de Paris, 94800 Villejuif — France
>
> tel: +33 (0) 1 42 11 93 25
>