All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: AnilKumar Ch <anilkumar@ti.com>,
	linux-can@vger.kernel.org, anantgole@ti.com, nsekhar@ti.com
Subject: Re: [PATCH 3/3] can: c_can: Add support for Bosch D_CAN controller
Date: Tue, 24 Apr 2012 10:31:37 +0200	[thread overview]
Message-ID: <4F9664E9.6000403@grandegger.com> (raw)
In-Reply-To: <4F965FF6.2020201@pengutronix.de>

On 04/24/2012 10:10 AM, Marc Kleine-Budde wrote:
> On 04/20/2012 11:58 AM, AnilKumar Ch wrote:
>> This patch adds the support for D_CAN controller driver to the existing
>> C_CAN driver.
>>
>> Bosch D_CAN controller is a full-CAN implementation which is compliant
>> to CAN protocol version 2.0 part A and B. Bosch D_CAN user manual can be
>> obtained from: http://www.semiconductors.bosch.de/media/en/pdf/
>> ipmodules_1/can/d_can_users_manual_111.pdf
>>
>> The following are the design choices made while adding D_CAN to C_CAN
>> driver:
>> A new overlay structure is added for d_can controller and care is taken
>> to make sure its member names match with equavalent c_can structure
>> members (even if the d_can specification calls them slightly differently).
>> Note that d_can controller has more registers, so structure members of
>> d_can are more than those in c_can.
>>
>> A new set if read/write macros are used to access the registers common
>> between c_can and d_can. To get the basic d_can functionality working
>> it is sufficient to access just these registers.
> 
> I don't like macros. I've two further possible solutions:

Yes, I don't like that part either, also because of the

  "if (priv->dev_type == DEV_TYPE_D_CAN)"

for each read/write access.

> a) Access the registers via an array. The array index is a "virtual"
>    register, the array's value the physical offset within the c_can or
>    d_can controller.

I was thinking about that as well but using absolute addresses. This
would avoid further calculations for 16/32 bit aligned accesses.

> b) AFAICS you need more than three registers to get the CAN core
>    working. Another possibility is to implement an accessor function
>   for each register.

... offsetof() might be useful for this approach.

> Other, hopefully better, solutions are open for discussion.

The solutions above are not really elegant, but so far I do not have
better ideas.

Wolfgang.


  reply	other threads:[~2012-04-24  8:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-20  9:58 [PATCH 3/3] can: c_can: Add support for Bosch D_CAN controller AnilKumar Ch
2012-04-24  8:10 ` Marc Kleine-Budde
2012-04-24  8:31   ` Wolfgang Grandegger [this message]
2012-04-24  8:36     ` Marc Kleine-Budde
2012-04-24  9:14       ` Wolfgang Grandegger
2012-04-24 11:42         ` AnilKumar, Chimata
2012-04-24 12:25           ` Wolfgang Grandegger

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=4F9664E9.6000403@grandegger.com \
    --to=wg@grandegger.com \
    --cc=anantgole@ti.com \
    --cc=anilkumar@ti.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=nsekhar@ti.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.