From: Simon Horman <simon.horman@corigine.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
Chandrasekar Ramakrishnan <rcsekar@samsung.com>,
Wolfgang Grandegger <wg@grandegger.com>,
Vincent MAILHOL <mailhol.vincent@wanadoo.fr>,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 08/18] can: m_can: Write transmit header and data in one transaction
Date: Sat, 4 Feb 2023 14:05:57 +0100 [thread overview]
Message-ID: <Y95YNQwMfTM2h7iW@corigine.com> (raw)
In-Reply-To: <20230130080419.dzdnmq4vtag7wbpd@blmsp>
On Mon, Jan 30, 2023 at 09:04:19AM +0100, Markus Schneider-Pargmann wrote:
> Hi Simon,
>
> On Thu, Jan 26, 2023 at 09:04:56AM +0100, Simon Horman wrote:
> > On Wed, Jan 25, 2023 at 08:50:49PM +0100, Markus Schneider-Pargmann wrote:
> > > Combine header and data before writing to the transmit fifo to reduce
> > > the overhead for peripheral chips.
> > >
> > > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > > ---
> > > drivers/net/can/m_can/m_can.c | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> > > index 78f6ed744c36..440bc0536951 100644
> > > --- a/drivers/net/can/m_can/m_can.c
> > > +++ b/drivers/net/can/m_can/m_can.c
> > > @@ -1681,6 +1681,7 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev)
> > > m_can_write(cdev, M_CAN_TXBAR, 0x1);
> > > /* End of xmit function for version 3.0.x */
> > > } else {
> > > + char buf[TXB_ELEMENT_SIZE];
> > > /* Transmit routine for version >= v3.1.x */
> > >
> > > txfqs = m_can_read(cdev, M_CAN_TXFQS);
> > > @@ -1720,12 +1721,11 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev)
> > > fifo_header.dlc = FIELD_PREP(TX_BUF_MM_MASK, putidx) |
> > > FIELD_PREP(TX_BUF_DLC_MASK, can_fd_len2dlc(cf->len)) |
> > > fdflags | TX_BUF_EFC;
> > > - err = m_can_fifo_write(cdev, putidx, M_CAN_FIFO_ID, &fifo_header, 2);
> > > - if (err)
> > > - goto out_fail;
> > > + memcpy(buf, &fifo_header, 8);
> > > + memcpy(&buf[8], &cf->data, cf->len);
> > >
> > > - err = m_can_fifo_write(cdev, putidx, M_CAN_FIFO_DATA,
> > > - cf->data, DIV_ROUND_UP(cf->len, 4));
> > > + err = m_can_fifo_write(cdev, putidx, M_CAN_FIFO_ID,
> > > + buf, 8 + DIV_ROUND_UP(cf->len, 4));
> >
> > Perhaps I am missing something here, but my reading is that:
> >
> > - 8 is a length in bytes
> > - the 5th argument to m_can_fifo_write is the val_count parameter,
> > whose unit is 4-byte long values.
> >
> > By this logic, perhaps the correct value for this argument is:
> >
> > DIV_ROUND_UP(8 + cf->len, 4)
>
> Thank you for spotting this. You are totally right, I will fix it for
> the next version.
Thanks.
> > Also:
> >
> > - If cf->len is not a multiple of 4, is there a possibility
> > that uninitialised trailing data in buf will be used
> > indirectly by m_can_fifo_write()?
>
> Good point. I think this can only happen for 1, 2, 3, 5, 6, 7 bytes,
> values above have to be multiple of 4 because of the CAN-FD
> specification.
>
> With 'buf' it should read garbage from the buffer which I think is not a
> problem as the chip knows how much of the data to use. Also the tx
> elemnt size is hardcoded to 64 byte in the driver, so we do not overwrite
> the next element with that. The chip minimum size is 8 bytes for the
> data field anyways. So I think this is fine.
I'm not the expert on the hw in question here, but intuitively
I do feel that it may be unwise to send uninitialised data.
While I'm happy to defer to you on this, I do wonder if it would be somehow
better to use memcpy_and_pad() in place of memcpy().
next prev parent reply other threads:[~2023-02-04 13:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 19:50 [PATCH v2 00/18] can: m_can: Optimizations for m_can/tcan part 2 Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 01/18] can: tcan4x5x: Remove reserved register 0x814 from writable table Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 02/18] can: tcan4x5x: Check size of mram configuration Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 03/18] can: m_can: Remove repeated check for is_peripheral Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 04/18] can: m_can: Always acknowledge all interrupts Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 05/18] can: m_can: Remove double interrupt enable Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 06/18] can: m_can: Disable unused interrupts Markus Schneider-Pargmann
2023-01-26 8:07 ` Simon Horman
2023-01-25 19:50 ` [PATCH v2 07/18] can: m_can: Keep interrupts enabled during peripheral read Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 08/18] can: m_can: Write transmit header and data in one transaction Markus Schneider-Pargmann
2023-01-26 8:04 ` Simon Horman
2023-01-30 8:04 ` Markus Schneider-Pargmann
2023-02-04 13:05 ` Simon Horman [this message]
2023-02-20 5:31 ` Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 09/18] can: m_can: Implement receive coalescing Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 10/18] can: m_can: Implement transmit coalescing Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 11/18] can: m_can: Add rx coalescing ethtool support Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 12/18] can: m_can: Add tx " Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 13/18] can: m_can: Cache tx putidx Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 14/18] can: m_can: Use the workqueue as queue Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 15/18] can: m_can: Introduce a tx_fifo_in_flight counter Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 16/18] can: m_can: Use tx_fifo_in_flight for netif_queue control Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 17/18] can: m_can: Implement BQL Markus Schneider-Pargmann
2023-01-25 19:50 ` [PATCH v2 18/18] can: m_can: Implement transmit submission coalescing Markus Schneider-Pargmann
2023-01-28 15:00 ` Vincent MAILHOL
2023-01-30 8:05 ` Markus Schneider-Pargmann
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=Y95YNQwMfTM2h7iW@corigine.com \
--to=simon.horman@corigine.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mkl@pengutronix.de \
--cc=msp@baylibre.com \
--cc=netdev@vger.kernel.org \
--cc=rcsekar@samsung.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).