From: Dan Murphy <dmurphy@ti.com> To: Wolfgang Grandegger <wg@grandegger.com>, mkl@pengutronix.de, davem@davemloft.net Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/3] can: m_can: Create m_can core to leverage common code Date: Wed, 31 Oct 2018 15:15:56 -0500 [thread overview] Message-ID: <349ef8be-f4c7-25cc-2c33-7ce1fd0b0f40@ti.com> (raw) In-Reply-To: <52811b27-00c0-f5e2-2b18-608ccf846723@grandegger.com> Wolfgang Thanks for the review On 10/27/2018 09:19 AM, Wolfgang Grandegger wrote: > Hello Dan, > > for the RFC, could you please just do the necessary changes to the > existing code. We can discuss about better names, etc. later. For > the review if the common code I quickly did: > > mv m_can.c m_can_platform.c > mv m_can_core.c m_can.c > > The file names are similar to what we have for the C_CAN driver. > > s/classdev/priv/ > variable name s/m_can_dev/priv/ > > Then your patch 1/3 looks as shown below. I'm going to comment on that > one. The comments start with "***".... > So you would like me to align the names with the c_can driver? <snip> > > *** I didn't review the rest of the patch for now. > snipped the code to reply to the comment. > Looking to the generic code, you didn't really change the way > the driver is accessing the registers. Also the interrupt handling > and rx polling is as it was before. Does that work properly using > the SPI interface of the TCAN4x5x? I don't want to change any of that yet. Maybe my cover letter was not clear or did not go through. But the intention was just to break out the functionality to create a MCAN framework that can be used by devices that contain the Bosch MCAN core and provider their own protocal to access the registers in the device. I don't want to do any functional changes at this time on the IP code itself until we have a framework. There should be no regression in the io mapped code. I did comment on the interrupt handling and asked if a threaded work queue would affect CAN timing. For the original TCAN driver this was the way it was implemented. > > I was also thinking about optimized read/write functions handling > more than 4 bytes of data, e.g. for the CAN payload data. That > would speed-up SPI transfers, I think. But that could also be > introduced later-on. That would be the plan. > > Wolfgang. > > > > -- ------------------ Dan Murphy
WARNING: multiple messages have this Message-ID (diff)
From: Dan Murphy <dmurphy@ti.com> To: Wolfgang Grandegger <wg@grandegger.com>, <mkl@pengutronix.de>, <davem@davemloft.net> Cc: <linux-can@vger.kernel.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 1/3] can: m_can: Create m_can core to leverage common code Date: Wed, 31 Oct 2018 15:15:56 -0500 [thread overview] Message-ID: <349ef8be-f4c7-25cc-2c33-7ce1fd0b0f40@ti.com> (raw) In-Reply-To: <52811b27-00c0-f5e2-2b18-608ccf846723@grandegger.com> Wolfgang Thanks for the review On 10/27/2018 09:19 AM, Wolfgang Grandegger wrote: > Hello Dan, > > for the RFC, could you please just do the necessary changes to the > existing code. We can discuss about better names, etc. later. For > the review if the common code I quickly did: > > mv m_can.c m_can_platform.c > mv m_can_core.c m_can.c > > The file names are similar to what we have for the C_CAN driver. > > s/classdev/priv/ > variable name s/m_can_dev/priv/ > > Then your patch 1/3 looks as shown below. I'm going to comment on that > one. The comments start with "***".... > So you would like me to align the names with the c_can driver? <snip> > > *** I didn't review the rest of the patch for now. > snipped the code to reply to the comment. > Looking to the generic code, you didn't really change the way > the driver is accessing the registers. Also the interrupt handling > and rx polling is as it was before. Does that work properly using > the SPI interface of the TCAN4x5x? I don't want to change any of that yet. Maybe my cover letter was not clear or did not go through. But the intention was just to break out the functionality to create a MCAN framework that can be used by devices that contain the Bosch MCAN core and provider their own protocal to access the registers in the device. I don't want to do any functional changes at this time on the IP code itself until we have a framework. There should be no regression in the io mapped code. I did comment on the interrupt handling and asked if a threaded work queue would affect CAN timing. For the original TCAN driver this was the way it was implemented. > > I was also thinking about optimized read/write functions handling > more than 4 bytes of data, e.g. for the CAN payload data. That > would speed-up SPI transfers, I think. But that could also be > introduced later-on. That would be the plan. > > Wolfgang. > > > > -- ------------------ Dan Murphy
next prev parent reply other threads:[~2018-10-31 20:15 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-10 14:20 [RFC PATCH 0/3] M_CAN Framework rework Dan Murphy 2018-10-10 14:20 ` Dan Murphy 2018-10-10 14:20 ` [RFC PATCH 1/3] can: m_can: Create m_can core to leverage common code Dan Murphy 2018-10-10 14:20 ` Dan Murphy 2018-10-27 14:19 ` Wolfgang Grandegger 2018-10-27 14:19 ` Wolfgang Grandegger 2018-10-31 20:15 ` Dan Murphy [this message] 2018-10-31 20:15 ` Dan Murphy 2018-11-03 10:45 ` Wolfgang Grandegger 2018-11-09 15:14 ` Dan Murphy 2018-11-09 15:14 ` Dan Murphy 2019-01-09 20:58 ` Dan Murphy 2019-01-09 20:58 ` Dan Murphy 2019-01-10 7:44 ` Wolfgang Grandegger 2019-01-10 7:57 ` Rizvi, Mohammad Faiz Abbas 2019-01-10 7:57 ` Rizvi, Mohammad Faiz Abbas 2019-01-10 12:54 ` Dan Murphy 2019-01-10 12:54 ` Dan Murphy 2019-01-10 12:53 ` Dan Murphy 2019-01-10 12:53 ` Dan Murphy 2019-01-11 8:27 ` Wolfgang Grandegger 2019-01-11 12:27 ` Dan Murphy 2019-01-11 12:27 ` Dan Murphy 2018-10-10 14:20 ` [RFC PATCH 2/3] dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver Dan Murphy 2018-10-10 14:20 ` Dan Murphy 2018-10-10 14:20 ` [RFC PATCH 3/3] can: tcan4x5x: Add tcan4x5x driver to the kernel Dan Murphy 2018-10-10 14:20 ` Dan Murphy 2018-10-17 20:21 ` [RFC PATCH 0/3] M_CAN Framework rework Dan Murphy 2018-10-17 20:21 ` Dan Murphy 2018-10-24 7:33 ` Faiz Abbas 2018-10-24 7:33 ` Faiz Abbas 2018-10-24 11:39 ` Dan Murphy 2018-10-24 11:39 ` Dan Murphy 2018-10-24 7:43 ` Wolfgang Grandegger 2018-10-24 11:36 ` Dan Murphy 2018-10-24 11:36 ` Dan Murphy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=349ef8be-f4c7-25cc-2c33-7ce1fd0b0f40@ti.com \ --to=dmurphy@ti.com \ --cc=davem@davemloft.net \ --cc=linux-can@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mkl@pengutronix.de \ --cc=netdev@vger.kernel.org \ --cc=wg@grandegger.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.