linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: stable@vger.kernel.org, Palmer Dabbelt <palmerdabbelt@google.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH] arm: Enlarge IO_SPACE_LIMIT needed for some SoC
Date: Sun, 9 May 2021 14:09:56 +0100	[thread overview]
Message-ID: <20210509130956.GI1336@shell.armlinux.org.uk> (raw)
In-Reply-To: <YJcV6I6yYt5zIsXQ@Ansuel-xps.localdomain>

On Sun, May 09, 2021 at 12:51:20AM +0200, Ansuel Smith wrote:
> On Sat, May 08, 2021 at 07:50:44PM +0100, Russell King - ARM Linux admin wrote:
> > On Sat, May 08, 2021 at 07:55:35PM +0200, Ansuel Smith wrote:
> > > Ipq8064 SoC requires larger IO_SPACE_LIMIT or second and third pci port
> > > fails to register the IO addresses and connected device doesn't work.
> > > 
> > > Cc: <stable@vger.kernel.org> # 4.9+
> > > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > 
> > I don't see any consideration of whether this increase results in any
> > clashes with any other related areas. Also, there is no update of the
> > memory layout documentation.
> > 
> > The memory layout documentation says:
> > 
> > =============== =============== ===============================================
> > Start           End             Use
> > =============== =============== ===============================================
> > fee00000        feffffff        Mapping of PCI I/O space. This is a static
> >                                 mapping within the vmalloc space.
> > 
> > which means there's a maximum of 0x001fffff available. You are
> > increasing it's size from 0x000fffff to 0x00ffffff. This means it
> > expands from 0xfee00000 through to 0xffdfffff.
> > 
> > This conflicts with these entries:
> > 
> > ffc80000        ffefffff        Fixmap mapping region.  Addresses provided
> >                                 by fix_to_virt() will be located here.
> > 
> > ffc00000        ffc7ffff        Guard region
> > 
> > ff800000        ffbfffff        Permanent, fixed read-only mapping of the
> >                                 firmware provided DT blob
> > 
> > So, I have no option but to NAK this change. Sorry.
> > 
> > You can find this documentation in the "Documentation" subdirectory.
> > 
> > -- 
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> 
> Hi,
> Thanks a lot for the review and sorry for the mess. Just to make sure I
> don't push a very wrong patch another time. ipq8064 require 0x300000 of
> IO space if all 3 lines are used. From what I can read in the
> documentation, the PCI I/O mapping section does have space and can be
> expanded to ff0fffff without causing collision. So I have to update that
> part and the IO_LIMIT to 0x2fffff. Tell me if I'm completely wrong and
> again, thanks for the review.

Well, an obvious question would be: do you really need that much IO
space? PCs have got away with 64K of IO space without having a problem
for years, so 64K per bus should be fine. If you have 3 buses, that
should be 3 * 64K or 192K.

I would bet in the normal circumstance that the IO space on every PCI
bus is very sparsely used, so using 1MiB per bus seems over the top.

That said, using 1MB each for three buses takes the top of the IO space
to 0xff100000, which shouldn't be a problem, assuming memory.rst is up
to date.

In any case, I really don't think such a change has anything to do with
stable kernels, so please drop that for your next submission.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-09 13:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08 17:55 [RESEND PATCH] arm: Enlarge IO_SPACE_LIMIT needed for some SoC Ansuel Smith
2021-05-08 18:50 ` Russell King - ARM Linux admin
2021-05-08 22:51   ` Ansuel Smith
2021-05-09 13:09     ` Russell King - ARM Linux admin [this message]
2021-05-09 16:54       ` David Laight

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=20210509130956.GI1336@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=ansuelsmth@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=palmerdabbelt@google.com \
    --cc=stable@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).