All of lore.kernel.org
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: Intel I350 mini-PCIe card (igb) on Mirabox (mvebu / Armada 370)
Date: Tue, 8 Apr 2014 20:01:40 +0200	[thread overview]
Message-ID: <20140408200140.5dcc2ad7@skate> (raw)
In-Reply-To: <20140408171417.GB27776@obsidianresearch.com>

Dear Jason Gunthorpe,

On Tue, 8 Apr 2014 11:14:17 -0600, Jason Gunthorpe wrote:

> > mvebu-mbus/devices output:
> > 
> > # cat /sys/kernel/debug/mvebu-mbus/devices 
> > [10] 00000000e0000000 - 00000000e0900000 : 0004:00e8
> 
> > I'm not sure why I don't have the non-power-of-two problem for the MBus
> > windows.
> 
> Well, you do, 0x900000 is not aligned. It converts to size=0b10001111,
> which is undefined behavior for mbus. 

Ah correct. Though I'm still puzzled as to why the undefined behavior
works for me, and not for Willy, who I believe has the same NIC as me.

> What do you think about this:
> 
> From 235b0bf637242a50ec45c8766d18a942bff601cf Mon Sep 17 00:00:00 2001
> From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Date: Tue, 8 Apr 2014 11:12:41 -0600
> Subject: [PATCH] bus: mvebu-mbus: Avoid setting an undefined window size
> 
> The mbus hardware requires a power of two size, if a non-power
> of two is passed in to the low level routines they configure the
> register in a way that results in undefined behaviour.
> 
> - WARN_ON to make this invalid usage really obvious
> - Round down to the nearest power of two so we only stuff a valid
>   size into the HW

I perfectly fine with those two.

> - When reading interpret undefined values in a conservative way,
>   the value is assumed to be the lowest power of two. This avoids
>   the debugfs output showing a value that looks 'correct'

But I am not sure with this one. Since now you're anyway rounding down
sizes, how is it possible to get a non-power-of-two size in the
registers?

I would probably prefer to have mvebu_devs_debug_show() do something
like:

                seq_printf(seq, "[%02d] %016llx - %016llx : %04x:%04x%s",
                           win, (unsigned long long)wbase,
                           (unsigned long long)(wbase + wsize), wtarget, wattr,
			   (!is_power_of_2(wsize)) ? " non-pow2 undefined behavior!" : "");

or something like that. This way at least the function does not "hide"
the fact that the configured value is invalid.

See one more comment below.

> All together this makes the recent problems with silent failure
> of PCI very obvious, noisy and debuggable.
> 
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
>  drivers/bus/mvebu-mbus.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
> index 2ac754e..d26f63c 100644
> --- a/drivers/bus/mvebu-mbus.c
> +++ b/drivers/bus/mvebu-mbus.c
> @@ -56,6 +56,7 @@
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/debugfs.h>
> +#include <linux/log2.h>
>  
>  /*
>   * DDR target is the same on all platforms.
> @@ -147,7 +148,7 @@ static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,
>  	*enabled = 1;
>  	*base = ((u64)basereg & WIN_BASE_HIGH) << 32;
>  	*base |= (basereg & WIN_BASE_LOW);
> -	*size = (ctrlreg | ~WIN_CTRL_SIZE_MASK) + 1;
> +	*size = 1 << (ffs(~(ctrlreg | ~WIN_CTRL_SIZE_MASK)) - 1);
>  
>  	if (target)
>  		*target = (ctrlreg & WIN_CTRL_TGT_MASK) >> WIN_CTRL_TGT_SHIFT;
> @@ -266,6 +267,9 @@ static int mvebu_mbus_setup_window(struct mvebu_mbus_state *mbus,
>  		mbus->soc->win_cfg_offset(win);
>  	u32 ctrl, remap_addr;
>  
> +	WARN_ON(!is_power_of_2(size));
> +	size = rounddown_pow_of_two(size);

Maybe something like:

	if (!is_power_of_2(size)) {
		WARN(true, "Invalid MBus window size: 0x%x, rounding down to 0x%x\n",
		     size, rounddown_pow_of_two(size));
		size = rounddown_pow_of_two(size);
	}

And while we're adding checks, why not also verify that the base
address is a multiple of the window size? I think it's the other
requirement.

That being said, this warning doesn't really solve the problem that the
PCI core may allocate BARs whose size cannot be represented through
MBus windows :-)

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2014-04-08 18:01 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25 20:07 Intel I350 mini-PCIe card (igb) on Mirabox (mvebu / Armada 370) Neil Greatorex
2014-03-25 20:20 ` Thomas Petazzoni
2014-03-25 21:03   ` Willy Tarreau
2014-03-25 20:22 ` Jason Gunthorpe
2014-03-25 20:36   ` Thomas Petazzoni
2014-03-25 21:12     ` Jason Gunthorpe
2014-03-25 21:23       ` Thomas Petazzoni
2014-03-25 22:03     ` Neil Greatorex
2014-03-25 22:24       ` Jason Gunthorpe
2014-03-25 22:35         ` Jason Gunthorpe
2014-03-26 19:31           ` Neil Greatorex
2014-03-26 20:12             ` Jason Gunthorpe
2014-03-26 20:34               ` Neil Greatorex
2014-03-26 21:42                 ` Jason Gunthorpe
2014-03-26 21:52                   ` Thomas Petazzoni
2014-03-27  0:29                   ` Neil Greatorex
2014-03-27  4:40                     ` Jason Gunthorpe
2014-03-28  1:03                       ` Neil Greatorex
2014-03-28  2:04                         ` Jason Gunthorpe
2014-04-04 13:19                         ` Neil Greatorex
2014-04-05 17:32                           ` Willy Tarreau
2014-04-05 17:34                           ` Thomas Petazzoni
2014-04-05 18:04                             ` Willy Tarreau
2014-04-05 18:55                               ` Neil Greatorex
2014-04-05 19:03                                 ` Willy Tarreau
2014-04-05 19:00                             ` Neil Greatorex
2014-04-06 15:34                               ` Neil Greatorex
2014-04-06 17:43                                 ` Willy Tarreau
2014-04-08 15:13                                 ` Thomas Petazzoni
2014-04-08 15:40                                   ` Thomas Petazzoni
2014-04-08 15:55                                     ` Thomas Petazzoni
2014-04-08 16:02                                       ` Matthew Minter
2014-04-08 17:14                                       ` Jason Gunthorpe
2014-04-08 17:53                                         ` Willy Tarreau
2014-04-08 18:08                                           ` Jason Gunthorpe
2014-04-08 18:15                                             ` Thomas Petazzoni
2014-04-08 18:40                                               ` Jason Gunthorpe
2014-04-08 19:15                                             ` Willy Tarreau
2014-04-08 19:21                                               ` Jason Gunthorpe
2014-04-08 20:17                                                 ` Matthew Minter
2014-04-08 21:50                                                   ` Thomas Petazzoni
2014-04-08 20:19                                                 ` Neil Greatorex
2014-04-08 20:43                                                 ` Willy Tarreau
2014-04-08 18:01                                         ` Thomas Petazzoni [this message]
2014-04-08 18:22                                           ` Jason Gunthorpe
2014-04-08 18:32                                             ` Thomas Petazzoni
2014-04-08 15:53                                   ` Willy Tarreau
2014-04-08 16:00                                     ` Thomas Petazzoni
2014-04-08 16:05                                       ` Willy Tarreau
2014-04-06 18:58                           ` Willy Tarreau
2014-04-06 19:11                             ` Thomas Petazzoni
2014-04-06 21:57                             ` Neil Greatorex
2014-04-06 22:04                               ` Willy Tarreau
2014-04-06 22:16                               ` Thomas Petazzoni
2014-04-07  0:50                                 ` Neil Greatorex
2014-04-07 17:41                               ` Jason Gunthorpe
2014-04-07 19:41                                 ` Neil Greatorex
2014-04-07 20:48                                   ` Jason Gunthorpe
2014-04-07 21:58                                     ` Neil Greatorex
2014-04-08  6:28                                       ` Willy Tarreau
2014-04-08  6:40                                       ` Willy Tarreau
2014-04-08 10:53                                         ` Matthew Minter
2014-04-08 12:31                                           ` Matthew Minter
2014-04-08 12:36                                             ` Willy Tarreau
2014-04-08 14:43                                               ` Thomas Petazzoni
2014-04-08 14:52                                                 ` Matthew Minter
2014-04-08 14:53                                                 ` Willy Tarreau
2014-04-08 15:25                                                   ` Thomas Petazzoni
2014-04-08 17:56                                             ` Willy Tarreau

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=20140408200140.5dcc2ad7@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.