[PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Pavel Pisa]

From: Ondrej Ille <ondrej.ille@gmail.com>

The Secondary Sample Point Source field has been
set to an incorrect value by some mistake in the
past

  0b01 - SSP_SRC_NO_SSP - SSP is not used.

for data bitrates above 1 MBit/s. The correct/default
value already used for lower bitrates is

  0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
         (Measured Transmitter delay) + SSP_OFFSET.

The related configuration register structure is described
in section 3.1.46 SSP_CFG of the CTU CAN FD
IP CORE Datasheet.

The analysis leading to the proper configuration
is described in section 2.8.3 Secondary sampling point
of the datasheet.

The change has been tested on AMD/Xilinx Zynq
with the next CTU CN FD IP core versions:

 - 2.6 aka master in the "integration with Zynq-7000 system" test
   6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
   driver (change already included in the driver repo)
 - older 2.5 snapshot with mainline kernels with this patch
   applied locally in the multiple CAN latency tester nightly runs
   6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
   6.19.0-rc3-dut

The logs, the datasheet and sources are available at

 https://canbus.pages.fel.cvut.cz/

Signed-off-by: Ondrej Ille <ondrej.ille@gmail.com>
Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
---
 drivers/net/can/ctucanfd/ctucanfd_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c b/drivers/net/can/ctucanfd/ctucanfd_base.c
index 1e6b9e3dc2fe..0ea1ff28dfce 100644
--- a/drivers/net/can/ctucanfd/ctucanfd_base.c
+++ b/drivers/net/can/ctucanfd/ctucanfd_base.c
@@ -310,7 +310,7 @@ static int ctucan_set_secondary_sample_point(struct net_device *ndev)
 		}
 
 		ssp_cfg = FIELD_PREP(REG_TRV_DELAY_SSP_OFFSET, ssp_offset);
-		ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x1);
+		ssp_cfg |= FIELD_PREP(REG_TRV_DELAY_SSP_SRC, 0x0);
 	}
 
 	ctucan_write32(priv, CTUCANFD_TRV_DELAY, ssp_cfg);
-- 
2.47.3

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On 05.01.2026 12:16:20, Pavel Pisa wrote:
> From: Ondrej Ille <ondrej.ille@gmail.com>
>
> The Secondary Sample Point Source field has been
> set to an incorrect value by some mistake in the
> past
>
>   0b01 - SSP_SRC_NO_SSP - SSP is not used.
>
> for data bitrates above 1 MBit/s. The correct/default
> value already used for lower bitrates is
>
>   0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
>          (Measured Transmitter delay) + SSP_OFFSET.
>
> The related configuration register structure is described
> in section 3.1.46 SSP_CFG of the CTU CAN FD
> IP CORE Datasheet.
>
> The analysis leading to the proper configuration
> is described in section 2.8.3 Secondary sampling point
> of the datasheet.
>
> The change has been tested on AMD/Xilinx Zynq
> with the next CTU CN FD IP core versions:
>
>  - 2.6 aka master in the "integration with Zynq-7000 system" test
>    6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
>    driver (change already included in the driver repo)
>  - older 2.5 snapshot with mainline kernels with this patch
>    applied locally in the multiple CAN latency tester nightly runs
>    6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
>    6.19.0-rc3-dut
>
> The logs, the datasheet and sources are available at
>
>  https://canbus.pages.fel.cvut.cz/
>
> Signed-off-by: Ondrej Ille <ondrej.ille@gmail.com>
> Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>

While applying, re-formated patch description and added the following tags:

| Reported-by: Andrea Daoud <andreadaoud6@gmail.com>
| Closes: https://lore.kernel.org/all/CAOprWotBRv_cvD3GCSe7N2tiLooZBoDisSwbu+VBAmt_2izvwQ@mail.gmail.com
| Cc: stable@vger.kernel.org
| Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")

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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Vincent Mailhol]

Le 05/01/2026 à 12:16, Pavel Pisa a écrit :
> From: Ondrej Ille <ondrej.ille@gmail.com>
> 
> The Secondary Sample Point Source field has been
> set to an incorrect value by some mistake in the
> past
> 
>   0b01 - SSP_SRC_NO_SSP - SSP is not used.
> 
> for data bitrates above 1 MBit/s. The correct/default
> value already used for lower bitrates is

Where does this 1 MBit/s threshold come from? Is this an empirical value?

The check is normally done on the data BRP. For example we had some
problems on the mcp251xfd, c.f. commit 5e1663810e11 ("can: mcp251xfd:
fix TDC setting for low data bit rates").

Can you use the TDC framework? Not only would you get a correct
calculation for when to activate/deactivate TDC, you will also have the
netlink reporting (refer to the above commit for an example).

>   0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
>          (Measured Transmitter delay) + SSP_OFFSET.
> 
> The related configuration register structure is described
> in section 3.1.46 SSP_CFG of the CTU CAN FD
> IP CORE Datasheet.
> 
> The analysis leading to the proper configuration
> is described in section 2.8.3 Secondary sampling point
> of the datasheet.
> 
> The change has been tested on AMD/Xilinx Zynq
> with the next CTU CN FD IP core versions:
> 
>  - 2.6 aka master in the "integration with Zynq-7000 system" test
>    6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
>    driver (change already included in the driver repo)
>  - older 2.5 snapshot with mainline kernels with this patch
>    applied locally in the multiple CAN latency tester nightly runs
>    6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
>    6.19.0-rc3-dut
> 
> The logs, the datasheet and sources are available at
> 
>  https://canbus.pages.fel.cvut.cz/
> 
> Signed-off-by: Ondrej Ille <ondrej.ille@gmail.com>
> Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>


Yours sincerely,
Vincent Mailhol

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Pavel Pisa]

Dear Vincent Mailhol,

thanks for pointing to Transmission Delay Compensation
related code introduced in 5.16 kernel. I have noticed it
in the past but not considered it yet and I think
that we need minimal fixes to help users and
allow change to propagate into stable series now.

More details inline

On Monday 05 of January 2026 21:27:11 Vincent Mailhol wrote:
> Le 05/01/2026 à 12:16, Pavel Pisa a écrit :
> > From: Ondrej Ille <ondrej.ille@gmail.com>
> >
> > The Secondary Sample Point Source field has been
> > set to an incorrect value by some mistake in the
> > past
> >
> >   0b01 - SSP_SRC_NO_SSP - SSP is not used.
> >
> > for data bitrates above 1 MBit/s. The correct/default
> > value already used for lower bitrates is
>
> Where does this 1 MBit/s threshold come from? Is this an empirical value?
>
> The check is normally done on the data BRP. For example we had some
> problems on the mcp251xfd, c.f. commit 5e1663810e11 ("can: mcp251xfd:
> fix TDC setting for low data bit rates").

The CTU CAN FD check is done on data bitrate

https://elixir.bootlin.com/linux/v6.18.3/source/drivers/net/can/ctucanfd/ctucanfd_base.c#L290

  if (dbt->bitrate > 1000000)

the line expands to

  if (priv->can.fd.data_bittiming.bitrate > 1000000)

The value computation has been defined by Ondrej Ille, main author
of the CTU CAN FD IP core. The main driver author has been
Martin Jerabek and there seems that we have made some mistake,
flip in value in the past. But Ondrej Ille is the most competent
for the core limits and intended behavior and SW support.
He has invested to complete iso-16845 compliance testing
framework re-implementation for detailed timing testing.
There is even simulated environment with clocks jitters
and delays equivalent to linear, start and other typologies
run at each core update. The kudos for idea how to implement
this without unacceptable time required for simulation
goes to Martin Jerabek. But lot of scenarios are tested
and Ondrej Ille can specify what is right and has been
tested. May it be, even Jiri Novak can provide some input
as well, because he uses CTU CAN FD to deliver more generations
of CTU tester systems to car makers (mainly SkodaAuto)
and the need of configurable IP core for these purposes was initial
driver for the CTU CAN FD core design.

The function of SSP is described in the datasheet and implementation
in the CTU CAN FD IP CORE System Architecture manual or we can go
to HDL design as well.

I extrapolate that 1 Mbit/s has been chosen as the switching point,
because controller and transceivers are expected to support
arbitration bit rate to at least 1 Mbit/s according to CAN and CAN FD
standards and there is no chance to use SSP during nominal bitrate.

> Can you use the TDC framework?

In longer term it would be right direction. But TRV_DELAY
measurement is and should be considered as default for
data bit rate and BRS set and then the transceiver delay
should be fully compensated on CTU CAN FD.

Problem was that the compensation was switched off by mistake
in the encoded value.

But when I study manuals and implementation again, I think that
there is problem with data bitrate < 1 Mbit/s, because for these
the compensation should be switched off or the data rate sample_point
should be recomputed to SSP_OFFET because else sampling is done
too early. Delay is not added to sampling point. So we should
correct this to make case with BRS and switching to
higher data rate (but under 1 Mbit/s) to be more reliable.

There are some limitations in maximal values which can be
set to SSP_OFFET field. It resolution is high, 10 ns typically
for our IP CORE FPGA targets with the 100 MHz IP core clock.
On silicon version, as I know, 80 MHz has been used in the
last integration. So again, limit is around 2.5 usec or a little
more for 80 MHz. This matches again mode switch at 1 Mbit/s
or the other option could be switch when SSP_OFFET exceeds
250 or some such value.

> Not only would you get a correct 
> calculation for when to activate/deactivate TDC, you will also have the
> netlink reporting (refer to the above commit for an example).

Yes, I agree that availability of tuning and monitoring over
netlink is nice added value. But at this moment I (personally)
prefer the minimal fix to help actual users.

I add there links to current CAN FD Transmission Delay Compensation
support and definition in the Linux kernel code for future integration
into CTU CAN FD IP core driver

https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/can/bittiming.h#L25

https://elixir.bootlin.com/linux/v6.18.3/source/drivers/net/can/dev/calc_bittiming.c#L174

https://elixir.bootlin.com/linux/v6.18.3/source/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c#L595

and in the controller features announcement

priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
		CAN_CTRLMODE_LISTENONLY | CAN_CTRLMODE_BERR_REPORTING |
		CAN_CTRLMODE_FD | CAN_CTRLMODE_FD_NON_ISO |
		CAN_CTRLMODE_CC_LEN8_DLC | CAN_CTRLMODE_TDC_AUTO |
		CAN_CTRLMODE_TDC_MANUAL;

Best wishes,

Pavel

> >   0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
> >          (Measured Transmitter delay) + SSP_OFFSET.
> >
> > The related configuration register structure is described
> > in section 3.1.46 SSP_CFG of the CTU CAN FD
> > IP CORE Datasheet.
> >
> > The analysis leading to the proper configuration
> > is described in section 2.8.3 Secondary sampling point
> > of the datasheet.
> >
> > The change has been tested on AMD/Xilinx Zynq
> > with the next CTU CN FD IP core versions:
> >
> >  - 2.6 aka master in the "integration with Zynq-7000 system" test
> >    6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
> >    driver (change already included in the driver repo)
> >  - older 2.5 snapshot with mainline kernels with this patch
> >    applied locally in the multiple CAN latency tester nightly runs
> >    6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
> >    6.19.0-rc3-dut
> >
> > The logs, the datasheet and sources are available at
> >
> >  https://canbus.pages.fel.cvut.cz/
> >
> > Signed-off-by: Ondrej Ille <ondrej.ille@gmail.com>
> > Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
>
> Yours sincerely,
> Vincent Mailhol

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Vincent Mailhol]

On 06/01/2026 at 01:53, Pavel Pisa wrote:
> Dear Vincent Mailhol,
> 
> thanks for pointing to Transmission Delay Compensation
> related code introduced in 5.16 kernel. I have noticed it
> in the past but not considered it yet and I think
> that we need minimal fixes to help users and
> allow change to propagate into stable series now.
> 
> More details inline
> 
> On Monday 05 of January 2026 21:27:11 Vincent Mailhol wrote:
>> Le 05/01/2026 à 12:16, Pavel Pisa a écrit :
>>> From: Ondrej Ille <ondrej.ille@gmail.com>
>>>
>>> The Secondary Sample Point Source field has been
>>> set to an incorrect value by some mistake in the
>>> past
>>>
>>>   0b01 - SSP_SRC_NO_SSP - SSP is not used.
>>>
>>> for data bitrates above 1 MBit/s. The correct/default
>>> value already used for lower bitrates is
>>
>> Where does this 1 MBit/s threshold come from? Is this an empirical value?
>>
>> The check is normally done on the data BRP. For example we had some
>> problems on the mcp251xfd, c.f. commit 5e1663810e11 ("can: mcp251xfd:
>> fix TDC setting for low data bit rates").
> 
> The CTU CAN FD check is done on data bitrate
> 
> https://elixir.bootlin.com/linux/v6.18.3/source/drivers/net/can/ctucanfd/ctucanfd_base.c#L290
> 
>   if (dbt->bitrate > 1000000)
> 
> the line expands to
> 
>   if (priv->can.fd.data_bittiming.bitrate > 1000000)
> 
> The value computation has been defined by Ondrej Ille, main author
> of the CTU CAN FD IP core. The main driver author has been
> Martin Jerabek and there seems that we have made some mistake,
> flip in value in the past. But Ondrej Ille is the most competent
> for the core limits and intended behavior and SW support.
> He has invested to complete iso-16845 compliance testing
> framework re-implementation for detailed timing testing.
> There is even simulated environment with clocks jitters
> and delays equivalent to linear, start and other typologies
> run at each core update. The kudos for idea how to implement
> this without unacceptable time required for simulation
> goes to Martin Jerabek. But lot of scenarios are tested
> and Ondrej Ille can specify what is right and has been
> tested. May it be, even Jiri Novak can provide some input
> as well, because he uses CTU CAN FD to deliver more generations
> of CTU tester systems to car makers (mainly SkodaAuto)
> and the need of configurable IP core for these purposes was initial
> driver for the CTU CAN FD core design.
> 
> The function of SSP is described in the datasheet and implementation
> in the CTU CAN FD IP CORE System Architecture manual or we can go
> to HDL design as well.
> 
> I extrapolate that 1 Mbit/s has been chosen as the switching point,
> because controller and transceivers are expected to support
> arbitration bit rate to at least 1 Mbit/s according to CAN and CAN FD
> standards and there is no chance to use SSP during nominal bitrate.
> 
>> Can you use the TDC framework?
> 
> In longer term it would be right direction. But TRV_DELAY
> measurement is and should be considered as default for
> data bit rate and BRS set and then the transceiver delay
> should be fully compensated on CTU CAN FD.
> 
> Problem was that the compensation was switched off by mistake
> in the encoded value.
> 
> But when I study manuals and implementation again, I think that
> there is problem with data bitrate < 1 Mbit/s, because for these
> the compensation should be switched off or the data rate sample_point
> should be recomputed to SSP_OFFET because else sampling is done
> too early. Delay is not added to sampling point. So we should
> correct this to make case with BRS and switching to
> higher data rate (but under 1 Mbit/s) to be more reliable.

Any issue that we witnessed in the past with low bitrates were only on
the drivers which had an hand coded TDC logic. Migrating those drivers
to the kernel TDC framework solved those issues without the need of an
additional check on the bitrate.

If you can show me a bus off condition in your device when using the
kernel TDC framework or if you can point me to publications from CAN in
Automation or similar which supports the idea of the 1 Mbit/s check,
then I can add that extra check to the framework. Otherwise, I would
like to drop this idea.

> There are some limitations in maximal values which can be
> set to SSP_OFFET field. It resolution is high, 10 ns typically
> for our IP CORE FPGA targets with the 100 MHz IP core clock.
> On silicon version, as I know, 80 MHz has been used in the
> last integration. So again, limit is around 2.5 usec or a little
> more for 80 MHz. This matches again mode switch at 1 Mbit/s
> or the other option could be switch when SSP_OFFET exceeds
> 250 or some such value.

Do you see any actual incompatibilities with the kernel TDC framework on
the offset maximum value?

>> Not only would you get a correct 
>> calculation for when to activate/deactivate TDC, you will also have the
>> netlink reporting (refer to the above commit for an example).
> 
> Yes, I agree that availability of tuning and monitoring over
> netlink is nice added value. But at this moment I (personally)
> prefer the minimal fix to help actual users.

We can also backport the fix if using the TDC framework. The ctucanfd
driver was introduced after the TDC framework so it will apply smoothly
to stable.

> I add there links to current CAN FD Transmission Delay Compensation
> support and definition in the Linux kernel code for future integration
> into CTU CAN FD IP core driver
> 
> https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/can/bittiming.h#L25
> 
> https://elixir.bootlin.com/linux/v6.18.3/source/drivers/net/can/dev/calc_bittiming.c#L174
> 
> https://elixir.bootlin.com/linux/v6.18.3/source/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c#L595
> 
> and in the controller features announcement
> 
> priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK |
> 		CAN_CTRLMODE_LISTENONLY | CAN_CTRLMODE_BERR_REPORTING |
> 		CAN_CTRLMODE_FD | CAN_CTRLMODE_FD_NON_ISO |
> 		CAN_CTRLMODE_CC_LEN8_DLC | CAN_CTRLMODE_TDC_AUTO |
> 		CAN_CTRLMODE_TDC_MANUAL;
> 
> Best wishes,
> 
> Pavel
> 
>>>   0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
>>>          (Measured Transmitter delay) + SSP_OFFSET.
>>>
>>> The related configuration register structure is described
>>> in section 3.1.46 SSP_CFG of the CTU CAN FD
>>> IP CORE Datasheet.
>>>
>>> The analysis leading to the proper configuration
>>> is described in section 2.8.3 Secondary sampling point
>>> of the datasheet.
>>>
>>> The change has been tested on AMD/Xilinx Zynq
>>> with the next CTU CN FD IP core versions:
>>>
>>>  - 2.6 aka master in the "integration with Zynq-7000 system" test
>>>    6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
>>>    driver (change already included in the driver repo)
>>>  - older 2.5 snapshot with mainline kernels with this patch
>>>    applied locally in the multiple CAN latency tester nightly runs
>>>    6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
>>>    6.19.0-rc3-dut
>>>
>>> The logs, the datasheet and sources are available at
>>>
>>>  https://canbus.pages.fel.cvut.cz/


Yours sincerely,
Vincent Mailhol

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On 06.01.2026 23:14:47, Vincent Mailhol wrote:
> > thanks for pointing to Transmission Delay Compensation
> > related code introduced in 5.16 kernel. I have noticed it
> > in the past but not considered it yet and I think
> > that we need minimal fixes to help users and
> > allow change to propagate into stable series now.

How to proceed. Take this fix now an (hopefully) port to the mainline
TDC framework later?

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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Vincent Mailhol]

On 09/01/2026 at 10:29, Marc Kleine-Budde wrote:
> On 06.01.2026 23:14:47, Vincent Mailhol wrote:
>>> thanks for pointing to Transmission Delay Compensation
>>> related code introduced in 5.16 kernel. I have noticed it
>>> in the past but not considered it yet and I think
>>> that we need minimal fixes to help users and
>>> allow change to propagate into stable series now.
> 
> How to proceed. Take this fix now an (hopefully) port to the mainline
> TDC framework later?

While I would definitely prefer to see the TDC framework implementation
rather than this quick fix, I will also not block it.

If you feel confident to continue with that patch, go ahead.

Yours sincerely,
Vincent Mailhol

Re: [PATCH v2] can: ctucanfd: fix SSP_SRC in cases when bit-rate is higher than 1 MBit.

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On 09.01.2026 11:50:42, Vincent Mailhol wrote:
> On 09/01/2026 at 10:29, Marc Kleine-Budde wrote:
> > On 06.01.2026 23:14:47, Vincent Mailhol wrote:
> >>> thanks for pointing to Transmission Delay Compensation
> >>> related code introduced in 5.16 kernel. I have noticed it
> >>> in the past but not considered it yet and I think
> >>> that we need minimal fixes to help users and
> >>> allow change to propagate into stable series now.
> >
> > How to proceed. Take this fix now an (hopefully) port to the mainline
> > TDC framework later?
>
> While I would definitely prefer to see the TDC framework implementation
> rather than this quick fix,

ACK

> I will also not block it.

thanks

> If you feel confident to continue with that patch, go ahead.

I think the patch has been tested and as far as I understood the patch
was used internally for some time. So applied to linux-can, added stable
on Cc and added a fixes tag.

thanks,
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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]