linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Markus Schneider-Pargmann <msp@baylibre.com>
To: Simon Horman <simon.horman@corigine.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: Mon, 30 Jan 2023 09:04:19 +0100	[thread overview]
Message-ID: <20230130080419.dzdnmq4vtag7wbpd@blmsp> (raw)
In-Reply-To: <Y9I0KEeWq0JFy6iB@corigine.com>

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.

> 
> 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.

Thanks,
Markus

> 
> >  		if (err)
> >  			goto out_fail;
> >  
> > -- 
> > 2.39.0
> > 

  reply	other threads:[~2023-01-30  8:04 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 [this message]
2023-02-04 13:05       ` Simon Horman
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=20230130080419.dzdnmq4vtag7wbpd@blmsp \
    --to=msp@baylibre.com \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=rcsekar@samsung.com \
    --cc=simon.horman@corigine.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).