All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dong Aisheng <b29396@freescale.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
	wg@grandegger.com, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] can: m_can: add Bosch M_CAN controller support
Date: Wed, 2 Jul 2014 14:33:49 +0800	[thread overview]
Message-ID: <20140702063348.GC10397@shlinux1.ap.freescale.net> (raw)
In-Reply-To: <53B3BB7E.6040903@pengutronix.de>

On Wed, Jul 02, 2014 at 09:57:50AM +0200, Marc Kleine-Budde wrote:
> On 07/02/2014 08:20 AM, Dong Aisheng wrote:
> [...]
> 
> >>> +static int m_can_do_rx_poll(struct net_device *dev, int quota)
> >>> +{
> >>> +	struct m_can_priv *priv = netdev_priv(dev);
> >>> +	struct net_device_stats *stats = &dev->stats;
> >>> +	struct sk_buff *skb;
> >>> +	struct can_frame *frame;
> >>> +	u32 rxfs, flags, fgi;
> >>> +	u32 num_rx_pkts = 0;
> >>> +
> >>> +	rxfs = m_can_read(priv, M_CAN_RXF0S);
> >>> +	if (!(rxfs & RXFS_FFL_MASK)) {
> >>> +		netdev_dbg(dev, "no messages in fifo0\n");
> >>> +		return 0;
> >>> +	}
> >>> +
> >>> +	while ((rxfs & RXFS_FFL_MASK) && (quota > 0)) {
> >>> +		netdev_dbg(dev, "fifo0 status 0x%x\n", rxfs);
> >>
> >> Please remove the netdev_dbg(), once the driver is stable it should be
> >> of no use.
> >>
> > 
> > Got it.
> > 
> >>> +		if (rxfs & RXFS_RFL)
> >>> +			netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
> >>
> >> What does that mean? Can you still rx the message if it's lost?
> >>
> > 
> > It just warns that there's a message lost, but there are still other
> > message in fifo to receive.
> > 
> >>> +
> >>> +		skb = alloc_can_skb(dev, &frame);
> >>> +		if (!skb) {
> >>> +			stats->rx_dropped++;
> >>> +			return -ENOMEM;
> >>
> >> Have a look at the user of m_can_do_rx_poll() and how it makes use of
> >> the return value.
> >>
> > 
> > Right, thanks for spotting it.
> > 
> >>> +		}
> >>> +
> >>> +		fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
> >>
> >> BTW: Is this a _real_ fifo? Or evolution of the c_can/d_can interface
> >> where it's not a fifo at all.
> >>
> > 
> > Yes, it is real fifo in the message ram.
> > 
> >>> +		flags = readl(priv->mram_base + priv->rxf0_off + fgi * 16);
> >>> +		if (flags & RX_BUF_XTD)
> >>> +			frame->can_id = (flags & CAN_EFF_MASK) | CAN_EFF_FLAG;
> >>> +		else
> >>> +			frame->can_id = (flags >> 18) & CAN_SFF_MASK;
> >>> +		netdev_dbg(dev, "R0 0x%x\n", flags);
> >>
> >> please remove dbg
> >>> +
> >>> +		if (flags & RX_BUF_RTR) {
> >>> +			frame->can_id |= CAN_RTR_FLAG;
> >>> +		} else {
> >>> +			flags = readl(priv->mram_base +
> >>> +					priv->rxf0_off + fgi * 16 + 0x4);
> >>> +			frame->can_dlc = get_can_dlc((flags >> 16) & 0x0F);
> >>> +			netdev_dbg(dev, "R1 0x%x\n", flags);
> >>
> >> please remove
> >>
> >>> +
> >>> +			*(u32 *)(frame->data + 0) = readl(priv->mram_base +
> >>> +					priv->rxf0_off + fgi * 16 + 0x8);
> >>> +			*(u32 *)(frame->data + 4) = readl(priv->mram_base +
> >>> +					priv->rxf0_off + fgi * 16 + 0xC);
> >>
> >>
> >> can you create a wrapper function to hide the pointer arithmetics here?
> >> Somethig like m_can_read_fifo()
> >>
> > 
> > Yes, i could make a wrapper function for it.
> > 
> >>> +			netdev_dbg(dev, "R2 0x%x\n", *(u32 *)(frame->data + 0));
> >>> +			netdev_dbg(dev, "R3 0x%x\n", *(u32 *)(frame->data + 4));
> >>> +		}
> >>> +
> >>> +		/* acknowledge rx fifo 0 */
> >>> +		m_can_write(priv, M_CAN_RXF0A, fgi);
> >>> +
> >>> +		netif_receive_skb(skb);
> >>> +		netdev_dbg(dev, "new packet received\n");
> >>> +
> >>> +		stats->rx_packets++;
> >>> +		stats->rx_bytes += frame->can_dlc;
> >>
> >> Please move the stats handling in front of netif_receive_skb() as the
> >> skb and thus frame is not a valid pointer anymore.
> >>
> > 
> > Good catch!
> > Will change it.
> > 
> >>> +
> >>> +		can_led_event(dev, CAN_LED_EVENT_RX);
> >>
> >> Please move out of the loop so that it is just called once (if a CAN
> >> frame is rx'ed) per  m_can_do_rx_poll().
> 
> > Why that?
> > The purpose is calling it for each new packet received.
> 
> It will only trigger LED blinking, and tglx pointed out, that we don't
> need the overhead of calling it for every CAN frame.
> 

Okay, got it, thanks for this information.

Regards
Dong Aisheng

> Marc
> 
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 



WARNING: multiple messages have this Message-ID (diff)
From: Dong Aisheng <b29396@freescale.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: <linux-can@vger.kernel.org>, <netdev@vger.kernel.org>,
	<wg@grandegger.com>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/3] can: m_can: add Bosch M_CAN controller support
Date: Wed, 2 Jul 2014 14:33:49 +0800	[thread overview]
Message-ID: <20140702063348.GC10397@shlinux1.ap.freescale.net> (raw)
In-Reply-To: <53B3BB7E.6040903@pengutronix.de>

On Wed, Jul 02, 2014 at 09:57:50AM +0200, Marc Kleine-Budde wrote:
> On 07/02/2014 08:20 AM, Dong Aisheng wrote:
> [...]
> 
> >>> +static int m_can_do_rx_poll(struct net_device *dev, int quota)
> >>> +{
> >>> +	struct m_can_priv *priv = netdev_priv(dev);
> >>> +	struct net_device_stats *stats = &dev->stats;
> >>> +	struct sk_buff *skb;
> >>> +	struct can_frame *frame;
> >>> +	u32 rxfs, flags, fgi;
> >>> +	u32 num_rx_pkts = 0;
> >>> +
> >>> +	rxfs = m_can_read(priv, M_CAN_RXF0S);
> >>> +	if (!(rxfs & RXFS_FFL_MASK)) {
> >>> +		netdev_dbg(dev, "no messages in fifo0\n");
> >>> +		return 0;
> >>> +	}
> >>> +
> >>> +	while ((rxfs & RXFS_FFL_MASK) && (quota > 0)) {
> >>> +		netdev_dbg(dev, "fifo0 status 0x%x\n", rxfs);
> >>
> >> Please remove the netdev_dbg(), once the driver is stable it should be
> >> of no use.
> >>
> > 
> > Got it.
> > 
> >>> +		if (rxfs & RXFS_RFL)
> >>> +			netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
> >>
> >> What does that mean? Can you still rx the message if it's lost?
> >>
> > 
> > It just warns that there's a message lost, but there are still other
> > message in fifo to receive.
> > 
> >>> +
> >>> +		skb = alloc_can_skb(dev, &frame);
> >>> +		if (!skb) {
> >>> +			stats->rx_dropped++;
> >>> +			return -ENOMEM;
> >>
> >> Have a look at the user of m_can_do_rx_poll() and how it makes use of
> >> the return value.
> >>
> > 
> > Right, thanks for spotting it.
> > 
> >>> +		}
> >>> +
> >>> +		fgi = (rxfs & RXFS_FGI_MASK) >> RXFS_FGI_OFF;
> >>
> >> BTW: Is this a _real_ fifo? Or evolution of the c_can/d_can interface
> >> where it's not a fifo at all.
> >>
> > 
> > Yes, it is real fifo in the message ram.
> > 
> >>> +		flags = readl(priv->mram_base + priv->rxf0_off + fgi * 16);
> >>> +		if (flags & RX_BUF_XTD)
> >>> +			frame->can_id = (flags & CAN_EFF_MASK) | CAN_EFF_FLAG;
> >>> +		else
> >>> +			frame->can_id = (flags >> 18) & CAN_SFF_MASK;
> >>> +		netdev_dbg(dev, "R0 0x%x\n", flags);
> >>
> >> please remove dbg
> >>> +
> >>> +		if (flags & RX_BUF_RTR) {
> >>> +			frame->can_id |= CAN_RTR_FLAG;
> >>> +		} else {
> >>> +			flags = readl(priv->mram_base +
> >>> +					priv->rxf0_off + fgi * 16 + 0x4);
> >>> +			frame->can_dlc = get_can_dlc((flags >> 16) & 0x0F);
> >>> +			netdev_dbg(dev, "R1 0x%x\n", flags);
> >>
> >> please remove
> >>
> >>> +
> >>> +			*(u32 *)(frame->data + 0) = readl(priv->mram_base +
> >>> +					priv->rxf0_off + fgi * 16 + 0x8);
> >>> +			*(u32 *)(frame->data + 4) = readl(priv->mram_base +
> >>> +					priv->rxf0_off + fgi * 16 + 0xC);
> >>
> >>
> >> can you create a wrapper function to hide the pointer arithmetics here?
> >> Somethig like m_can_read_fifo()
> >>
> > 
> > Yes, i could make a wrapper function for it.
> > 
> >>> +			netdev_dbg(dev, "R2 0x%x\n", *(u32 *)(frame->data + 0));
> >>> +			netdev_dbg(dev, "R3 0x%x\n", *(u32 *)(frame->data + 4));
> >>> +		}
> >>> +
> >>> +		/* acknowledge rx fifo 0 */
> >>> +		m_can_write(priv, M_CAN_RXF0A, fgi);
> >>> +
> >>> +		netif_receive_skb(skb);
> >>> +		netdev_dbg(dev, "new packet received\n");
> >>> +
> >>> +		stats->rx_packets++;
> >>> +		stats->rx_bytes += frame->can_dlc;
> >>
> >> Please move the stats handling in front of netif_receive_skb() as the
> >> skb and thus frame is not a valid pointer anymore.
> >>
> > 
> > Good catch!
> > Will change it.
> > 
> >>> +
> >>> +		can_led_event(dev, CAN_LED_EVENT_RX);
> >>
> >> Please move out of the loop so that it is just called once (if a CAN
> >> frame is rx'ed) per  m_can_do_rx_poll().
> 
> > Why that?
> > The purpose is calling it for each new packet received.
> 
> It will only trigger LED blinking, and tglx pointed out, that we don't
> need the overhead of calling it for every CAN frame.
> 

Okay, got it, thanks for this information.

Regards
Dong Aisheng

> Marc
> 
> -- 
> Pengutronix e.K.                  | Marc Kleine-Budde           |
> Industrial Linux Solutions        | Phone: +49-231-2826-924     |
> Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |
> 



  reply	other threads:[~2014-07-02  8:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 10:00 [PATCH 0/3] can: m_can: add Bosch M_CAN controller support Dong Aisheng
2014-06-27 10:00 ` Dong Aisheng
2014-06-27 10:00 ` [PATCH 1/3] " Dong Aisheng
2014-06-27 10:00   ` Dong Aisheng
2014-06-27 12:35   ` Mark Rutland
2014-06-30  8:03     ` Dong Aisheng
2014-06-27 18:03   ` Oliver Hartkopp
2014-06-30  8:26     ` Dong Aisheng
2014-06-30  8:26       ` Dong Aisheng
2014-07-02 17:54       ` Oliver Hartkopp
2014-07-02 19:13         ` Marc Kleine-Budde
2014-07-03  3:48           ` Dong Aisheng
2014-07-03  7:12             ` Marc Kleine-Budde
2014-07-03  8:48               ` Dong Aisheng
     [not found]                 ` <20140703084803.GA11012-KgLukfWpBlCctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-07-03  9:04                   ` Marc Kleine-Budde
2014-07-03  9:09                     ` Dong Aisheng
2014-07-03  9:20                       ` Marc Kleine-Budde
2014-07-03 10:39                         ` Dong Aisheng
2014-07-01 10:29   ` Marc Kleine-Budde
2014-07-02  6:20     ` Dong Aisheng
2014-07-02  6:20       ` Dong Aisheng
2014-07-02  7:57       ` Marc Kleine-Budde
2014-07-02  6:33         ` Dong Aisheng [this message]
2014-07-02  6:33           ` Dong Aisheng
2014-07-01 10:33   ` Marc Kleine-Budde
2014-06-27 10:00 ` [PATCH 2/3] can: m_can: add bus error handling Dong Aisheng
2014-06-27 10:00   ` Dong Aisheng
2014-07-01 10:37   ` Marc Kleine-Budde
2014-07-02  6:31     ` Dong Aisheng
2014-07-02  6:31       ` Dong Aisheng
2014-06-27 10:00 ` [PATCH 3/3] can: m_can: add loopback and monitor mode support Dong Aisheng
2014-06-27 10:00   ` Dong Aisheng
2014-07-01 10:38   ` Marc Kleine-Budde
2014-07-02  6:32     ` Dong Aisheng
2014-07-02  6:32       ` Dong Aisheng

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=20140702063348.GC10397@shlinux1.ap.freescale.net \
    --to=b29396@freescale.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-can@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: link
Be 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.