public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/5] pci: tegra: make tegra_pcie_port_reset weak function with explicit index
Date: Mon, 7 Aug 2017 12:47:43 +0000	[thread overview]
Message-ID: <1502110060.6745.4.camel@toradex.com> (raw)
In-Reply-To: <5d3dc5de-19cb-d48e-ef24-f02fabbb9f49@wwwdotorg.org>

Hi Stephen

On Fri, 2017-08-04 at 10:33 -0600, Stephen Warren wrote:
> On 08/04/2017 10:10 AM, Marcel Ziswiler wrote:
> > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > 
> > Make tegra_pcie_port_reset() a weak function with an explicit index
> > parameter. This allows overriding the PCIe port reset functionality
> > from board specific code as e.g. required for Apalis TK1.
> 
> I think this change should be implemented differently.
> 
> Does the patch description mean that:
> 
> a) This change allows the board code to know which port is being
> reset.
> 
> If so, simply have the board-specific implementation access port-
> >index 
> since it's already being passed port, and all callers are passing 
> port->index as the index parameter. If the type isn't available,
> then 
> you can add a tegra_pcie_port_index_of_port() function to retrieve
> it 
> through the opaque type.

I did of course know that the port struct already contained that
information but did not think of any such elegant way to do it as you
describe outside of adding an explicit index. So I agree and will just
implement and make use of such a new tegra_pcie_port_index_of_port()
function.

> or:
> 
> b) That by changing the function signature code is able to choose 
> between calling the board-specific reset override function and the
> PCIe 
> driver low-level reset function?
> 
> If so, let's just have two different function names, have all
> callers 
> call the board-specific function only, and have the board-specific 
> function call the driver function. There can be a weak default 
> board-specific implementation that simply calls the driver function.

Initially that was not really my intention but I believe you bring up a
 very valid point and it could be useful to use the default reset
behaviour on certain ports while using a custom one on others. This
would e.g. be the case on Apalis T30 where the on-module PCIe gigabit
Ethernet chip is using the standard out-of-band signalling while the
PCIe switch on the Apalis Evaluation board requires the same special
reset work-around as optionally implemented for Apalis TK1. I will
therefore implement it this way as well leaving it completely up to
board code which way to go.

Thanks again for your valuable input.

Cheers

Marcel

  reply	other threads:[~2017-08-07 12:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04 16:09 [U-Boot] [PATCH 0/5] fix apalis-tk1 pcie gigabit ethernet operation Marcel Ziswiler
2017-08-04 16:10 ` [U-Boot] [PATCH 1/5] configs: apalis-tk1: fix boot failure using ext4 rootfs Marcel Ziswiler
2017-08-04 16:10 ` [U-Boot] [PATCH 2/5] apalis-tk1: add missing as3722 gpio0 configuration Marcel Ziswiler
2017-08-06  5:16   ` Simon Glass
2017-08-04 16:10 ` [U-Boot] [PATCH 3/5] pci: tegra: make tegra_pcie_port_reset weak function with explicit index Marcel Ziswiler
2017-08-04 16:33   ` Stephen Warren
2017-08-07 12:47     ` Marcel Ziswiler [this message]
2017-08-04 16:10 ` [U-Boot] [PATCH 4/5] power: as3722: add as3722_ldo_set_voltage signature to header file Marcel Ziswiler
2017-08-06  5:16   ` Simon Glass
2017-08-04 16:10 ` [U-Boot] [PATCH 5/5] apalis-tk1: fix pcie reset for reliable gigabit ethernet operation Marcel Ziswiler

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=1502110060.6745.4.camel@toradex.com \
    --to=marcel.ziswiler@toradex.com \
    --cc=u-boot@lists.denx.de \
    /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