| Message ID | 20230427204540.3126234-6-dario.binacchi@amarulasolutions.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
Hi Dario,
kernel test robot noticed the following build errors:
[auto build test ERROR on mkl-can-next/testing]
[also build test ERROR on net-next/main net/main linus/master next-20230427]
[cannot apply to atorgue-stm32/stm32-next v6.3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Dario-Binacchi/dt-bindings-net-can-add-st-can-secondary-property/20230428-044723
base: https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git testing
patch link: https://lore.kernel.org/r/20230427204540.3126234-6-dario.binacchi%40amarulasolutions.com
patch subject: [PATCH v2 5/5] ARM: dts: stm32: add CAN support on stm32f746
config: arm-randconfig-r011-20230427 (https://download.01.org/0day-ci/archive/20230428/202304281111.wSsZVm5t-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/efdb48d32dc845ff8f52bfe8c7345b61c9671940
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Dario-Binacchi/dt-bindings-net-can-add-st-can-secondary-property/20230428-044723
git checkout efdb48d32dc845ff8f52bfe8c7345b61c9671940
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202304281111.wSsZVm5t-lkp@intel.com/
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/stm32f746.dtsi:265.20-21 syntax error
FATAL ERROR: Unable to parse input tree
On 27.04.2023 22:45:40, Dario Binacchi wrote: > Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The > chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral > configuration and CAN3 in single peripheral configuration: > - Dual CAN peripheral configuration: > * CAN1: Primary bxCAN for managing the communication between a secondary > bxCAN and the 512-byte SRAM memory. > * CAN2: Secondary bxCAN with no direct access to the SRAM memory. > This means that the two bxCAN cells share the 512-byte SRAM memory and > CAN2 can't be used without enabling CAN1. > - Single CAN peripheral configuration: > * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and > 512-byte SRAM memory. > > ------------------------------------------------------------------------- > | features | CAN1 | CAN2 | CAN 3 | > ------------------------------------------------------------------------- > | SRAM | 512-byte shared between CAN1 & CAN2 | 512-byte | > ------------------------------------------------------------------------- > | Filters | 26 filters shared between CAN1 & CAN2 | 14 filters | > ------------------------------------------------------------------------- > > Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> I initially upstreamed this patch as 0920ccdf41e3 ("ARM: dts: stm32: add CAN support on stm32f746"), but it depends on "dt-bindings: mfd: stm32f7: add binding definition for CAN3" [1], which is missing in net/main, resulting in parsing errors in the "stm32f746.dtsi". This patch is reverted by [2], so please upstream it via the platform maintainers. regards, Marc [1] https://lore.kernel.org/all/20230423172528.1398158-2-dario.binacchi@amarulasolutions.com [2] https://lore.kernel.org/all/20230517181950.1106697-1-mkl@pengutronix.de
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi index dc868e6da40e..973698bc9ef4 100644 --- a/arch/arm/boot/dts/stm32f746.dtsi +++ b/arch/arm/boot/dts/stm32f746.dtsi @@ -257,6 +257,23 @@ rtc: rtc@40002800 { status = "disabled"; }; + can3: can@40003400 { + compatible = "st,stm32f4-bxcan"; + reg = <0x40003400 0x200>; + interrupts = <104>, <105>, <106>, <107>; + interrupt-names = "tx", "rx0", "rx1", "sce"; + resets = <&rcc STM32F7_APB1_RESET(CAN3)>; + clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN3)>; + st,gcan = <&gcan3>; + status = "disabled"; + }; + + gcan3: gcan@40003600 { + compatible = "st,stm32f4-gcan", "syscon"; + reg = <0x40003600 0x200>; + clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN3)>; + }; + usart2: serial@40004400 { compatible = "st,stm32f7-uart"; reg = <0x40004400 0x400>; @@ -337,6 +354,36 @@ i2c4: i2c@40006000 { status = "disabled"; }; + can1: can@40006400 { + compatible = "st,stm32f4-bxcan"; + reg = <0x40006400 0x200>; + interrupts = <19>, <20>, <21>, <22>; + interrupt-names = "tx", "rx0", "rx1", "sce"; + resets = <&rcc STM32F7_APB1_RESET(CAN1)>; + clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN1)>; + st,can-primary; + st,gcan = <&gcan1>; + status = "disabled"; + }; + + gcan1: gcan@40006600 { + compatible = "st,stm32f4-gcan", "syscon"; + reg = <0x40006600 0x200>; + clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN1)>; + }; + + can2: can@40006800 { + compatible = "st,stm32f4-bxcan"; + reg = <0x40006800 0x200>; + interrupts = <63>, <64>, <65>, <66>; + interrupt-names = "tx", "rx0", "rx1", "sce"; + resets = <&rcc STM32F7_APB1_RESET(CAN2)>; + clocks = <&rcc 0 STM32F7_APB1_CLOCK(CAN2)>; + st,can-secondary; + st,gcan = <&gcan1>; + status = "disabled"; + }; + cec: cec@40006c00 { compatible = "st,stm32-cec"; reg = <0x40006C00 0x400>;
Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. ------------------------------------------------------------------------- | features | CAN1 | CAN2 | CAN 3 | ------------------------------------------------------------------------- | SRAM | 512-byte shared between CAN1 & CAN2 | 512-byte | ------------------------------------------------------------------------- | Filters | 26 filters shared between CAN1 & CAN2 | 14 filters | ------------------------------------------------------------------------- Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> --- Changes in v2: - Move after the patch "can: bxcan: add support for single peripheral configuration". - Add node gcan3. - Rename gcan as gcan1. - Add property "st,can-secondary" to can2 node. - Drop patch "dt-bindings: mfd: stm32f7: add binding definition for CAN3" because it has been accepted. - Add patch "ARM: dts: stm32f429: put can2 in secondary mode". - Add patch "dt-bindings: net: can: add "st,can-secondary" property". arch/arm/boot/dts/stm32f746.dtsi | 47 ++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)