LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Micha Nelissen <micha@neli.hopto.org>
To: "Bounine, Alexandre" <Alexandre.Bounine@idt.com>
Cc: Alexandre Bounine <alexb@tundra.com>,
	linux-kernel@vger.kernel.org, thomas.moll@sysgo.com,
	linuxppc-dev@lists.ozlabs.org, thomas.moll.ext@nsn.com
Subject: Re: [PATCH 3/7] RapidIO: Add Port-Write handling for EM
Date: Thu, 25 Feb 2010 22:02:42 +0100	[thread overview]
Message-ID: <4B86E572.6090101@neli.hopto.org> (raw)
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E552A5508A@CORPEXCH1.na.ads.idt.com>

Bounine, Alexandre wrote:
> Micha Nelissen wrote:
>> Alexandre Bounine wrote:
>>>  /**
>>> + * rio_em_set_ops- Sets Error Managment operations for a particular
> vendor switch
>>> + * @rdev: RIO device
>>> + *
>>> + * Searches the RIO EM ops table for known switch types. If the vid
>>> + * and did match a switch table entry, then set the em_init() and
>>> + * em_handle() ops to the table entry values.
>> Shouldn't any RIO device be able to support error management, not just
>> switches?
> 
> Only if a device reports this capability by having Error Management
> Extended Features block.
> Ideally, we have to provide default handler for every such device (I am
> planning it for some future updates). It should be the same as for
> routing operations - if the standard feature exists, it has to be used
> unless something else takes over.

Yes, therefore I thought that: or the EM_OPS are per driver, or they can 
be integrated in the switch hooks list.

> For now I keep all port-write messages from end-points serviced by their
> individual drivers. One of reasons for this: the EM PW message format

Maybe have a generic rio function that can be called by any driver that 
knows a particular port-write was due to error management causes? This 
function would read the standard defined EF block registers. Then the 
driver part can be quite small.

>>> +	if (port->ops->pwenable)
>>> +		port->ops->pwenable(port, enable);
>>> +}
>>> +
>> Maybe this can be done by switch->init function?
> 
> This is not per-switch function. This function enables mport to receive
> incoming PW messages. Per-switch PW enable is done in switch->init as
> for Tsi57x. 

Oops, I meant this comment for the em_init function call.

>>> +			rio_mport_write_config_32(mport, destid,
> hopcount,
>>> +				rdev->phys_efptr +
>>> +					RIO_PORT_N_ACK_STS_CSR(portnum),
>>> +				RIO_PORT_N_ACK_CLEAR);
>> This doesn't work for the 568; but the 568 has no special handling?
> 
> Tsi568 will not send EM PW message. Tsi568 PWs are disabled in its
> em_init().

Why?

>>> +DECLARE_RIO_EM_OPS(RIO_VID_TUNDRA, RIO_DID_TSI578, tsi57x_em_init,
> tsi57x_em_handler);
>> Why not declare these along with the other ops?
> 
> Because the EM extensions is a separate capability. It is not guaranteed
> to be in every switch.

They might initialize them with NULL to indicate they don't support it?

Micha

  reply	other threads:[~2010-02-25 21:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 15:24 [PATCH 3/7] RapidIO: Add Port-Write handling for EM Alexandre Bounine
2010-02-24 20:17 ` Micha Nelissen
2010-02-25 20:30   ` Bounine, Alexandre
2010-02-25 21:02     ` Micha Nelissen [this message]
2010-02-26 20:20       ` Bounine, Alexandre

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=4B86E572.6090101@neli.hopto.org \
    --to=micha@neli.hopto.org \
    --cc=Alexandre.Bounine@idt.com \
    --cc=alexb@tundra.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=thomas.moll.ext@nsn.com \
    --cc=thomas.moll@sysgo.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