public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: andrew.chih.howe.khor@intel.com,
	Masayuki Ohtake <masa-korg@dsn.okisemi.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	margie.foster@intel.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, socketcan-core@lists.berlios.de,
	yong.y.wang@intel.com, kok.howg.ewe@intel.com,
	joel.clark@intel.com, "David S. Miller" <davem@davemloft.net>,
	Christian Pellegrin <chripell@fsfe.org>,
	qi.wang@intel.com
Subject: Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings
Date: Wed, 03 Nov 2010 17:15:42 +0100	[thread overview]
Message-ID: <4CD18AAE.9040300@grandegger.com> (raw)
In-Reply-To: <4CCE9F0B.1000901@pengutronix.de>

On 11/01/2010 12:05 PM, Marc Kleine-Budde wrote:
> Hello,
> 
> On 10/29/2010 09:32 PM, Wolfgang Grandegger wrote:
> 
> some comments inline.
> 
> [...]
...
>>>> +	if (status & PCH_LEC_ALL) {
>>>> +		priv->can.can_stats.bus_error++;
>>>> +		stats->rx_errors++;
>>>> +		switch (status & PCH_LEC_ALL) {
>>>
>>> I suggest to convert to a if-bit-set because there might be more than
>>> one bit set.
>>
>> Marc, what do you mean here. It's an enumeraton. Maybe the following
>> code is more clear:
> 
> Oh, I haven't looked this one up in the datasheet.
>>
>> 	lec = status & PCH_LEC_ALL;
>> 	if (lec > 0) {
> 
> or "if (lec)", YMMV
> 
>> 		switch (lec) {
>>
>>>> +		case PCH_STUF_ERR:
>>>> +			cf->data[2] |= CAN_ERR_PROT_STUFF;
>>>> +			break;
>>>> +		case PCH_FORM_ERR:
>>>> +			cf->data[2] |= CAN_ERR_PROT_FORM;
>>>> +			break;
>>>> +		case PCH_ACK_ERR:
>>>> +			cf->data[2] |= CAN_ERR_PROT_LOC_ACK |
>>>> +				       CAN_ERR_PROT_LOC_ACK_DEL;
>>
>> Could you check what that type of bus error that is? Usually it's a ack
>> lost error.
>>
>>>> +			break;
>>>> +		case PCH_BIT1_ERR:
>>>> +		case PCH_BIT0_ERR:
>>>> +			cf->data[2] |= CAN_ERR_PROT_BIT;
>>>> +			break;
>>>> +		case PCH_CRC_ERR:
>>>> +			cf->data[2] |= CAN_ERR_PROT_LOC_CRC_SEQ |
>>>> +				       CAN_ERR_PROT_LOC_CRC_DEL;
>>>> +			break;
>>>> +		default:
>>>> +			iowrite32(status | PCH_LEC_ALL, &priv->regs->stat);
>>>> +			break;
>>>> +		}
>>>> +
>>>> +	}

At a closer look, I doubt that the above LEC handling is correct.
According to the manual: "when the LEC shows the value “7,” this value
was written to the LEC by the CPU; thus, no CAN bus event was detected"
Therefore the LEC bits should be properly *initialized* and *reset* to
0x7, which I do not find in the code.

Wolfgang.


  reply	other threads:[~2010-11-03 16:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29 10:37 [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build warnings Tomoya
2010-10-29 12:57 ` Marc Kleine-Budde
2010-10-29 16:23   ` Marc Kleine-Budde
2010-10-29 19:32     ` Wolfgang Grandegger
2010-11-01 11:05       ` Marc Kleine-Budde
2010-11-03 16:15         ` Wolfgang Grandegger [this message]
2010-11-12 11:10       ` Tomoya MORINAGA
2010-11-12 11:45         ` Wolfgang Grandegger
2010-11-15  7:39           ` Tomoya MORINAGA
2010-11-15  8:39       ` Tomoya MORINAGA
2010-11-02 10:27     ` Tomoya MORINAGA
2010-11-02 11:03       ` Marc Kleine-Budde
2010-11-15  8:41         ` Tomoya MORINAGA
2010-10-29 16:46   ` Oliver Hartkopp
2010-10-29 17:58     ` Marc Kleine-Budde
2010-11-09 12:26     ` Tomoya MORINAGA
2010-11-09 14:47       ` Marc Kleine-Budde
2010-11-01  7:15   ` Tomoya MORINAGA
     [not found] <005301cb7ffa$5b63cd90$66f8800a@maildom.okisemi.com>
2010-11-09 12:26 ` Tomoya MORINAGA
2010-11-09 12:59   ` Marc Kleine-Budde
2010-11-11  9:56     ` Tomoya MORINAGA
2010-11-11 10:04       ` Marc Kleine-Budde
  -- strict thread matches above, loose matches on Subject: below --
2010-10-26  0:04 Tomoya
2010-10-26 17:52 ` David Miller
2010-10-26 17:55   ` David Miller
2010-10-26 18:27     ` Wolfgang Grandegger
2010-10-26 18:52       ` Marc Kleine-Budde
2010-10-27  0:50       ` Tomoya MORINAGA
2010-10-25  2:32 Tomoya
2010-10-25 19:14 ` David Miller

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=4CD18AAE.9040300@grandegger.com \
    --to=wg@grandegger.com \
    --cc=andrew.chih.howe.khor@intel.com \
    --cc=chripell@fsfe.org \
    --cc=davem@davemloft.net \
    --cc=joel.clark@intel.com \
    --cc=kok.howg.ewe@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=margie.foster@intel.com \
    --cc=masa-korg@dsn.okisemi.com \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=qi.wang@intel.com \
    --cc=sameo@linux.intel.com \
    --cc=socketcan-core@lists.berlios.de \
    --cc=yong.y.wang@intel.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