linux-kernel - Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CCAC4CD.7000503@pengutronix.de>
Date:	Fri, 29 Oct 2010 14:57:49 +0200
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Tomoya <tomoya-linux@....okisemi.com>
CC:	Wolfgang Grandegger <wg@...ndegger.com>,
	"David S. Miller" <davem@...emloft.net>,
	Wolfram Sang <w.sang@...gutronix.de>,
	Christian Pellegrin <chripell@...e.org>,
	Barry Song <21cnbao@...il.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	socketcan-core@...ts.berlios.de, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, andrew.chih.howe.khor@...el.com,
	qi.wang@...el.com, margie.foster@...el.com, yong.y.wang@...el.com,
	Masayuki Ohtake <masa-korg@....okisemi.com>,
	kok.howg.ewe@...el.com, joel.clark@...el.com
Subject: Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Fix build
 warnings

Hello,

On 10/29/2010 12:37 PM, Tomoya wrote:
>>>> what does this loop do? why is it nessecarry? I don't like delay loops
>>>>   in the hot path of a driver.
>>> This loop is for waiting for all tx Message Object completion.
>>> This is Topcliff CAN HW specification.
>> What do you mean with "tx Message Object completion"? Is TX done not
>> signaled via interrupt?
> Yes Tx done is signaled via interrupt.
> On the other hand, register "CANTREQx" also shows the status of Message Object.
> Reading the register, CAN driver can know the Message Object is empty or not.
> In case of this processing, using this register is better, I think.
> 
>> Please explain why you need to wait multiples of
>>> 500us here in the hot TX path.
> You are right. The value "500us" was too big.
> According to Topcliff document, it takes 3~6 cycles for transferring between
> register and Message Object RAM.
> Since 50MHz is, 1cycle=0.02usec, 6cycle=0.12. May be true.
> I will modify 500usec to 1usec.
> 
>>>>> All these check if busy in the code make me a bit nervous, can you
>>>>> please explain why they are needed. A pointer to the manual is okay, too.
>>>> Me too. I already ask in my previous mail how long that functions
>>>> usually blocks.
>>> When accessing read/write from/to Message RAM,
>>> Since it takes much time for transferring between Register and Message RAM,
>> Much time means how many mirco-seconds?
> ditto
> 
>>> SW must check busy flag of CAN register.
>>> This is a Topcliff HW specification.
>> Maybe the busy check could also be done *before* the Message RAM is
>> accessed to avoid (or minimize) waiting.
> Yes, *before* is right.
> If there is *after* processing, this is a bug.
> Can you see anyway ?

Sorry I don't understand what you mean.

>> Can you give us a pointer into intel's documentation?
> You have already had Intel's data sheet(Topcliff/Atom E6xx series), right ?
> What's document for ?

You probably know the datasheet, but I don't, although I've printed
chapter 13 from the Intel Controller Hub EG20T datasheet, but it's 50+
pages. If the hardware needs the busy waiting in the hot tx path a
pointer to the respective section in the manual is a good idea. Just
something like:

    According to the Datasheet $REFERENCE section $SECTION_NUMBER we
    need to wait until the $FOO operation finished.

>>> If you figured out how to use the endianess conversion functions from
>>> the cpu_to_{le,be}-{le,to}_to_cpup family use them here, too.

> Sorry, I misunderstood the spec of Topcliff CAN endianess.
> I have understood endianess conversion is not necessary.
> (CAN data is set as Big-Endian in Topcliff CAN register)

>> You have to change the definition of the regs struct a bit:
>>> 	u32 if1_mcont;
>>> 	u32 if1_data[4];
>>> 	u32 reserve2;
> Uh, I can't find this. Where is this ?

Here's a patch to illustrate what I meant:

diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 55ec324..5ee7589 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -150,10 +150,7 @@ struct pch_can_regs {
        u32 if1_id1;
        u32 if1_id2;
        u32 if1_mcont;
-       u32 if1_dataa1;
-       u32 if1_dataa2;
-       u32 if1_datab1;
-       u32 if1_datab2;
+       u32 if1_data[4];
        u32 reserve2;
        u32 reserve3[12];
        u32 if2_creq;

>> BTW: Where can I get this Intel Hardware to improve and test the driver?
> We don't know, please contact to Intel,
> Topcliff is formally called "Atom E6xx series" http://edc.intel.com/Platforms/Atom-E6xx/

> I have completed modifying for your comments excepting above.
> Receiving many comments, your indication may be dropped. If you find, please indicate again?.
> For your confirming my modification, I show current whole of CAN driver.

The driver has already been merged. Please send incremental patches
against david's net-2.6 branch.

Cheers, 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   |


Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)