From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63A51C2BA83 for ; Fri, 14 Feb 2020 09:33:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2CDF4222C2 for ; Fri, 14 Feb 2020 09:33:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=walle.cc header.i=@walle.cc header.b="jow0IQnY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729087AbgBNJd3 (ORCPT ); Fri, 14 Feb 2020 04:33:29 -0500 Received: from ssl.serverraum.org ([176.9.125.105]:42807 "EHLO ssl.serverraum.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728807AbgBNJd3 (ORCPT ); Fri, 14 Feb 2020 04:33:29 -0500 Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 0377522FB6; Fri, 14 Feb 2020 10:33:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1581672806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N8SmNhdMY8qx5pj4Vo7NJU1TqLaS1FwOIi0U+8UWf5U=; b=jow0IQnY/XW+UNNnWLTz3oPkgWsBjbx5QarPXEvfjcXyo5jTi2/Pc8APgpo1py3JkTQH25 +ceZVCZRfr396NDXbVRE6xj5EqfytE1zdhKoqxEbqKUmDNAKj7QGAZaQU1lHatPrZJDd/p iCNOUe/Usk3mCHLzvA8wuSi7RGL2TyA= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 14 Feb 2020 10:33:25 +0100 From: Michael Walle To: Joakim Zhang Cc: Marc Kleine-Budde , wg@grandegger.com, netdev@vger.kernel.org, linux-can@vger.kernel.org, Pankaj Bansal , Shawn Guo Subject: Re: [PATCH 0/8] can: flexcan: add CAN FD support for NXP Flexcan In-Reply-To: References: <24eb5c67-4692-1002-2468-4ae2e1a6b68b@pengutronix.de> <20200213192027.4813-1-michael@walle.cc> <2322fb83486c678917957d9879e27e63@walle.cc> Message-ID: X-Sender: michael@walle.cc User-Agent: Roundcube Webmail/1.3.10 X-Spamd-Bar: / X-Rspamd-Server: web X-Rspamd-Queue-Id: 0377522FB6 X-Spamd-Result: default: False [-0.10 / 15.00]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM(-0.00)[-0.904]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[] Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Am 2020-02-14 10:18, schrieb Joakim Zhang: > Best Regards, > Joakim Zhang > >> -----Original Message----- >> From: Michael Walle >> Sent: 2020年2月14日 16:43 >> To: Joakim Zhang >> Cc: Marc Kleine-Budde ; wg@grandegger.com; >> netdev@vger.kernel.org; linux-can@vger.kernel.org; Pankaj Bansal >> >> Subject: Re: [PATCH 0/8] can: flexcan: add CAN FD support for NXP >> Flexcan >> >> Hi Joakim, >> >> Am 2020-02-14 02:55, schrieb Joakim Zhang: >> > Hi Michal, >> > >> >> -----Original Message----- >> >> From: Michael Walle >> >> Sent: 2020年2月14日 3:20 >> >> To: Marc Kleine-Budde >> >> Cc: Joakim Zhang ; wg@grandegger.com; >> >> netdev@vger.kernel.org; linux-can@vger.kernel.org; Pankaj Bansal >> >> ; Michael Walle >> >> Subject: Re: [PATCH 0/8] can: flexcan: add CAN FD support for NXP >> >> Flexcan >> >> >> >> Hi, >> >> >> >> >>> Are you prepared to add back these patches as they are necessary >> >> >>> for Flexcan CAN FD? And this Flexcan CAN FD patch set is based on >> >> >>> these patches. >> >> >> >> >> >> Yes, these patches will be added back. >> >> > >> >> >I've cleaned up the first patch a bit, and pushed everything to the >> >> >testing branch. Can you give it a test. >> >> >> >> What happend to that branch? FWIW I've just tried the patches on a >> >> custom board with a LS1028A SoC. Both CAN and CAN-FD are working. >> >> I've tested against a Peaktech USB CAN adapter. I'd love to see these >> >> patches upstream, because our board also offers CAN and basic support >> >> for it just made it upstream [1]. >> > The FlexCAN CAN FD related patches have stayed in >> > linux-can-next/flexcan branch for a long time, I still don't know why >> > Marc doesn't merge them into Linux mainline. >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. >> > >> kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fmkl%2Flinux-can-next.g >> > >> it%2Ftree%2F%3Fh%3Dflexcan&data=02%7C01%7Cqiangqing.zhang%40n >> xp.co >> > >> m%7C94dca4472a584410b3b908d7b129db27%7C686ea1d3bc2b4c6fa92cd99c >> 5c30163 >> > >> 5%7C0%7C0%7C637172665642079192&sdata=77tG6VuQCi%2FZXBKb23 >> 8%2FdNSV3 >> > NUIFrM5Y0e9yj0J3os%3D&reserved=0 >> > Also must hope that this patch set can be upstreamed soon. :-) >> >> I've took them from this branch and applied them to the latest linux >> master. >> >> Thus, >> >> Tested-by: Michael Walle >> >> >> >> If these patches are upstream, only the device tree nodes seems to be >> >> missing. >> >> I don't know what has happened to [2]. But the patch doesn't seem to >> >> be necessary. >> > Yes, this patch is unnecessary. I have NACKed this patch for that, >> > according to FlexCAN Integrated Guide, CTRL1[CLKSRC]=0 select >> > oscillator clock and CTRL1[CLKSRC]=1 select peripheral clock. >> > But it is actually decided by SoC integration, for i.MX, the design is >> > different. >> >> ok thanks for clarifying. >> >> > I have not upstream i.MX FlexCAN device tree nodes, since it's >> > dependency have not upstreamed yet. >> > >> >> Pankaj already send a patch to add the device node to the LS1028A [3]. >> >> Thats basically the same I've used, only that mine didn't had the >> >> "fsl,ls1028ar1-flexcan" compatiblity string, but only the >> >> "lx2160ar1-flexcan" >> >> which is the correct way to use it, right? >> > You can see below table from FlexCAN driver, "fsl,lx2160ar1-flexcan" >> > supports CAN FD, you can use this compatible string. >> >> correct. I've already a patch that does exactly this ;) Who would take >> the patch >> for adding the LS1028A can device tree nodes to ls1028a.dtsi? You or >> Shawn >> Guo? > Sorry, I missed the link[3], we usually write it this way: > compatible = "fsl,ls1028ar1-flexcan","fsl,lx2160ar1-flexcan"; > Please send patch to Shawn Guo, he will review the device tree. As far as I know, there should be no undocumented binding. Eg. the ls1028ar1-flexcan is neither in the source nor in the device tree binding documentation, thus wouldn't be accepted. Thus either there should be another ls1028ar1-flexcan in the flexcan_of_match table and the node should only contain that string or the node should only contain fsl,lx2160ar1-flexcan. Is there any advantage of the first option? -michael > >> > static const struct of_device_id flexcan_of_match[] = { >> > { .compatible = "fsl,imx8qm-flexcan", .data = >> > &fsl_imx8qm_devtype_data, }, >> > { .compatible = "fsl,imx6q-flexcan", .data = &fsl_imx6q_devtype_data, >> > }, >> > { .compatible = "fsl,imx28-flexcan", .data = &fsl_imx28_devtype_data, >> > }, >> > { .compatible = "fsl,imx53-flexcan", .data = &fsl_imx25_devtype_data, >> > }, >> > { .compatible = "fsl,imx35-flexcan", .data = &fsl_imx25_devtype_data, >> > }, >> > { .compatible = "fsl,imx25-flexcan", .data = &fsl_imx25_devtype_data, >> > }, >> > { .compatible = "fsl,p1010-flexcan", .data = &fsl_p1010_devtype_data, >> > }, >> > { .compatible = "fsl,vf610-flexcan", .data = &fsl_vf610_devtype_data, >> > }, >> > { .compatible = "fsl,ls1021ar2-flexcan", .data = >> > &fsl_ls1021a_r2_devtype_data, }, >> > { .compatible = "fsl,lx2160ar1-flexcan", .data = >> > &fsl_lx2160a_r1_devtype_data, }, >> > { /* sentinel */ }, >> > }; >> > >> >> -michael