Re: [PATCH v5 5/6] can: ctucanfd: CTU CAN FD open-source IP core - platform and next steps and mainlining chances
From: Randy Dunlap
Date: Tue Aug 25 2020 - 11:11:14 EST
On 8/25/20 2:25 AM, Pavel Pisa wrote:
> Hello Randy and Rob,
>
> thanks much for review, I have corrected FPGA spelling
> and binding YAML license.
>
> On Sunday 16 of August 2020 01:28:13 Randy Dunlap wrote:
>> On 8/15/20 12:43 PM, Pavel Pisa wrote:
>>> diff --git a/drivers/net/can/ctucanfd/Kconfig
>>> b/drivers/net/can/ctucanfd/Kconfig index e1636373628a..a8c9cc38f216
>>> 100644
>>> --- a/drivers/net/can/ctucanfd/Kconfig
>>> +++ b/drivers/net/can/ctucanfd/Kconfig
>>> @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
>>> PCIe board with PiKRON.com designed transceiver riser shield is
>>> available at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
>>>
>>> +config CAN_CTUCANFD_PLATFORM
>>> + tristate "CTU CAN-FD IP core platform (FPGA, SoC) driver"
>>> + depends on OF
>>
>> Can this be
>> depends on OF || COMPILE_TEST
>> ?
>
> I am not sure for this change. Is it ensured/documented somewhere that
> header files provide dummy definition such way, that OF drivers builds
> even if OF support is disabled? If I remember well, CTU CAN FD OF
> module build fails if attempted in the frame of native x86_64
> build where OF has been disabled. Does COMPILE_TEST ensure that
> such build succeeds.
>
COMPILE_TEST won't ensure anything.
OTOH, <linux/of.h> has lots of stubs for handling the case of
CONFIG_OF not being enabled.
--
~Randy