* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Ard Biesheuvel @ 2018-01-05 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105160617.GC17349@kroah.com>
On 5 January 2018 at 16:06, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote:
>> On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote:
>> > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote:
>> >> On 12/11/2017 09:59 AM, Catalin Marinas wrote:
>> >>> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote:
>> >>>> Patches are also pushed here:
>> >>>>
>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti
>> >>>>
>> >>>> Feedback and testing welcome. At this point, I'd like to start thinking
>> >>>> about getting this merged for 4.16.
>> >>>
>> >>> For the record, the fixed up version was pushed by Will here:
>> >>>
>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti
>> >>>
>> >>> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as
>> >>> above).
>> >>
>> >> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there
>> >> a plan to get the ARM64/KPTI patches backported towards stable trees as
>> >> well?
>> >
>> > Stable tree patches have to get into Linus's tree first before I can do
>> > anything :)
>> >
>> > Anyway, once that happens, yes, there is a plan, but it's a bit
>> > "different", and I'll talk about it once these are merged.
>>
>> Great, thanks! Bonus question, if someone is using any of the affected
>> devices in AArch32, should we be expecting to see ARM/Linux changes as
>> well, that is, is there a plan to come up with a kpti implementation for
>> ARM?
>
> I have not heard of anyone working on this for any arm32 platforms,
> as of this time, sorry.
>
> Which makes me worry about my android tv, glad I don't connect it to the
> network :(
>
The only ARM variant that is currently known to be affected by
Meltdown/variant 3 (which is what KPTI addresses) is the Cortex-A75,
which is a 64-bit core. That still means 32-bit guests running under
KVM will be affected, as well as a 32-bit kernel running on the bare
metal, but in practice, 32-bit ARM simply doesn't need KPTI. (My KASLR
patches for ARM are a bit in limbo atm, but those would benefit from
unmapping the kernel while running in userland as well)
As for variants 1/2 aka Spectre, I suppose ARM will need to implement
the same nospec/retpoline primitives that are being proposed for other
arches, but that work is not as fleshed out yet.
^ permalink raw reply
* [GIT PULL 4/5] Freescale arm64 device tree updates for 4.16
From: Arnd Bergmann @ 2018-01-05 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-4-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-4.16
>
> for you to fetch changes up to 1e33300782235ae6fdc891d9c3ba04ba59da6f3d:
>
> arm64: dts: ls208xa: add power monitor chip node (2017-12-26 17:14:13 +0800)
>
> ----------------------------------------------------------------
> Freescale arm64 device tree updates for 4.16:
> - LS1088A updates: add device support for DCFG, qoriq-mc, and USB.
> - Add power monitor device INA220 for ls208xa-rdb board.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.16 (#2)
From: Gregory CLEMENT @ 2018-01-05 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878tdcbu69.fsf@free-electrons.com>
Hi,
On ven., janv. 05 2018, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi,
>
> Here is the second pull request for dt64 for mvebu for v4.16.
Please do not pull this version but the second version I have just sent.
Thanks,
Gregory
>
> Gregory
>
> The following changes since commit 4cada03801992d09ccceaf5f462e9dadb75a9613:
>
> ARM64: dts: marvell: Add thermal support for A7K/A8K (2017-12-18 17:13:17 +0100)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.16-2
>
> for you to fetch changes up to 38027b7d7c27c185a3e4e70f8d83509c3eda0daf:
>
> arm64: dts: marvell: add Ethernet aliases (2018-01-03 17:07:50 +0100)
>
> ----------------------------------------------------------------
> mvebu dt64 for 4.16 (part 2)
>
> The main change here are the series of commits doing the Armada 7K/8K
> CP110 DT de-duplication, they include the de-duplication itself and
> small fixes in the device tree files.
>
> Besides them there are 2 other patches:
> - One adding the crypto support for Armada 37xx SoCs
> - An other adding Ethernet aliases on A7K/A8K base boards
>
> ----------------------------------------------------------------
> Antoine Tenart (1):
> arm64: dts: marvell: armada-37xx: add a crypto node
>
> Thomas Petazzoni (8):
> arm64: dts: marvell: fix watchdog unit address in Armada AP806
> arm64: dts: marvell: use lower case for unit address and reg property
> arm64: dts: marvell: fix typos in comment describing the NAND controller
> arm64: dts: marvell: fix compatible string list for Armada CP110 slave NAND
> arm64: dts: marvell: use mvebu-icu.h where possible
> arm64: dts: marvell: use aliases for SPI busses on Armada 7K/8K
> arm64: dts: marvell: de-duplicate CP110 description
> arm64: dts: marvell: replace cpm by cp0, cps by cp1
>
> Yan Markman (1):
> arm64: dts: marvell: add Ethernet aliases
>
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 14 +
> arch/arm64/boot/dts/marvell/armada-7040-db.dts | 52 +--
> arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 37 +-
> arch/arm64/boot/dts/marvell/armada-8020.dtsi | 2 +-
> arch/arm64/boot/dts/marvell/armada-8040-db.dts | 87 ++--
> arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 82 ++--
> arch/arm64/boot/dts/marvell/armada-8040.dtsi | 2 +-
> arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 80 +++-
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 8 +-
> arch/arm64/boot/dts/marvell/armada-common.dtsi | 10 +
> .../boot/dts/marvell/armada-cp110-master.dtsi | 449 ---------------------
> .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 448 --------------------
> arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 422 +++++++++++++++++++
> 13 files changed, 668 insertions(+), 1025 deletions(-)
> create mode 100644 arch/arm64/boot/dts/marvell/armada-common.dtsi
> delete mode 100644 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> delete mode 100644 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> create mode 100644 arch/arm64/boot/dts/marvell/armada-cp110.dtsi
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.16 (#2)
From: Arnd Bergmann @ 2018-01-05 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fu7k9tdn.fsf@free-electrons.com>
On Fri, Jan 5, 2018 at 5:12 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi,
>
> On ven., janv. 05 2018, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
>
>> Hi,
>>
>> Here is the second pull request for dt64 for mvebu for v4.16.
>
> Please do not pull this version but the second version I have just sent.
Good timing, I just started pulling it and pressed CTRL-C after seeing
you reply ;-)
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.15 (#1)
From: Gregory CLEMENT @ 2018-01-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lghc9urs.fsf@free-electrons.com>
Hi,
On ven., janv. 05 2018, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi,
>
> Here is the first pull request for fixes for mvebu for v4.15.
>
> Gregory
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.15-1
>
> for you to fetch changes up to fefb476bc7fdda4cb1e768493128c15a896f2c4e:
>
> ARM64: dts: marvell: armada-cp110: Fix clock resources for various node (2018-01-05 16:04:53 +0100)
>
Actually I fix the commit log of the patch "ARM64: dts: marvell:
armada-cp110: Fix clock resources for various node" by replacing
"logical" by "functional" which should make more sens. That means the
the commit ID had changes and should be:
e3af9f7c6ece29fdb7fe0aeb83ac5d3077a06edb:
ARM64: dts: marvell: armada-cp110: Fix clock resources for various node (2018-01-05 16:54:40 +0100)
Gregory
> ----------------------------------------------------------------
> mvebu fixess for 4.15 (part 1)
>
> 2 device tree related fixes fixing 2 issues:
> - broken pinctrl support since 4.11 on OpenBlocks A7
> - implicit clock dependency making the kernel hang if the Xenon sdhci
> module was loaded before the mvpp2 Ethernet support (for this one
> the driver had to be fixed which was done in v4.14)
>
> ----------------------------------------------------------------
> Gregory CLEMENT (1):
> ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
>
> Thomas Petazzoni (1):
> ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
>
> arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 13 ++++++++-----
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 9 ++++++---
> 3 files changed, 22 insertions(+), 10 deletions(-)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.16 (#2) (version 2)
From: Arnd Bergmann @ 2018-01-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k1ww9tgz.fsf@free-electrons.com>
On Fri, Jan 5, 2018 at 5:10 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi,
>
> Here is the second pull request for dt64 for mvebu for v4.16 which
> replace the previous one.
>
> Indeed I had to push a fix which conflicted with the change done on the
> armada-cp110 files. Resolving the conflict was not automatic, so I chose
> to merge the mvebu/fixes branch in the mvebu/dt64 branch, as at the end
> during the merge window for 4.16 the content of mvebu/fixes would have
> been already merged in 4.15.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH -next] clk: meson-axg: fix potential NULL dereference in axg_clkc_probe()
From: Stephen Boyd @ 2018-01-05 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515143370.7439.62.camel@baylibre.com>
On 01/05, Jerome Brunet wrote:
> On Fri, 2018-01-05 at 01:50 +0000, Wei Yongjun wrote:
> > platform_get_resource() may return NULL, add proper
> > check to avoid potential NULL dereferencing.
> >
> > This is detected by Coccinelle semantic patch.
> >
> > @@
> > expression pdev, res, n, t, e, e1, e2;
> > @@
> >
> > res = platform_get_resource(pdev, t, n);
> > + if (!res)
> > + return -EINVAL;
> > ... when != res == NULL
> > e = devm_ioremap(e1, res->start, e2);
> >
> > Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> > ---
>
> Looks good. Thank you.
>
> Stephen, do you prefer to take this directly ?
Yes. Will do today.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL
From: Rob Herring @ 2018-01-05 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102164059.14641-1-stefan@agner.ch>
On Tue, Jan 02, 2018 at 05:40:59PM +0100, Stefan Agner wrote:
> From: Bai Ping <ping.bai@nxp.com>
>
> On i.MX 6ULL, the BOOT_MODEx and TAMPERx pin MUX and CTRL registers
> are available in a separate IOMUXC_SNVS module. Add support for the
> IOMUXC_SNVS module to the i.MX 6UL pinctrl driver.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> .../bindings/pinctrl/fsl,imx6ul-pinctrl.txt | 3 +-
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/freescale/pinctrl-imx6ul.c | 52 +++++++++++++++++++++-
> 2 files changed, 52 insertions(+), 3 deletions(-)
^ permalink raw reply
* [GIT PULL v2 2/2] TI DaVinci DT updates for v4.16
From: Arnd Bergmann @ 2018-01-05 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105145248.1994-2-nsekhar@ti.com>
On Fri, Jan 5, 2018 at 3:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> ----------------------------------------------------------------
> A DT warning fix for W=1 warning message.
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH 2/7] ARM: dts: imx6ul: update i.MX 6UltraLite iomux headers
From: Rob Herring @ 2018-01-05 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102164223.15230-2-stefan@agner.ch>
On Tue, Jan 02, 2018 at 05:42:18PM +0100, Stefan Agner wrote:
> From: Fugang Duan <fugang.duan@nxp.com>
>
> Update i.MX 6UltraLite IOMUXC pin defines.
That's obvious reading the diff. The commit message should tell me why.
They were wrong?
>
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
^ permalink raw reply
* [RESEND PATCH] Wind down ARM/TANGO port
From: Arnd Bergmann @ 2018-01-05 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3313974f-b241-1915-5c0c-22040e67dec0@sigmadesigns.com>
On Fri, Jan 5, 2018 at 12:24 PM, Marc Gonzalez
<marc_gonzalez@sigmadesigns.com> wrote:
> This is the end. Update port status. Change contact address. Add Mans.
>
> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> ---
> Sigma is being sold. It is unlikely the STB unit will survive.
Applied to next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.15 (#1)
From: Arnd Bergmann @ 2018-01-05 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmi89t53.fsf@free-electrons.com>
On Fri, Jan 5, 2018 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
>>
>> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.15-1
>>
>> for you to fetch changes up to fefb476bc7fdda4cb1e768493128c15a896f2c4e:
>>
>> ARM64: dts: marvell: armada-cp110: Fix clock resources for various node (2018-01-05 16:04:53 +0100)
>>
>
> Actually I fix the commit log of the patch "ARM64: dts: marvell:
> armada-cp110: Fix clock resources for various node" by replacing
> "logical" by "functional" which should make more sens. That means the
> the commit ID had changes and should be:
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [PATCH 3/7] ARM: dts: imx6ull: add additional pinfunc defines for i.MX 6ULL
From: Rob Herring @ 2018-01-05 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102164223.15230-3-stefan@agner.ch>
On Tue, Jan 02, 2018 at 05:42:19PM +0100, Stefan Agner wrote:
> From: Bai Ping <ping.bai@nxp.com>
>
> On i.MX 6ULL, the pin MUX and CTRL register of BOOT_MODEx and TAMPERx
> pins are available through IOMUXC_SNVS. Add additional pinfunc defines.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> arch/arm/boot/dts/imx6ull-pinfunc-snvs.h | 29 +++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx6ull.dtsi | 1 +
> 2 files changed, 30 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
>
> diff --git a/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h b/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
> new file mode 100644
> index 000000000000..da3f412e4269
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ull-pinfunc-snvs.h
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
It's 2018 now.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
Use SPDX. With that,
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.16, step 2
From: Arnd Bergmann @ 2018-01-05 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105102203.braqydzlkoy5tk3v@flea.lan>
On Fri, Jan 5, 2018 at 11:22 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Arnd, Olof,
>
> Happy new year :)
>
> Here is the second bunch of changes we talked about in our first PR.
>
> There's one fix for 4.16, and the other patches have been around for
> quite a while that I'm feeling confident that we should merge them.
Pulled into next/dt
> On a side note, my GPG key changed recently. The new fingerprint is
> 2BA0E943D27E3D2094B10B24D824ECA89C346DCE, and you'll find that it has
> been signed by a bunch of kernel developpers already. The old one is
> superseeded, but has not been compromised.
Ok.
Arnd
^ permalink raw reply
* [GIT PULL 2/5] i.MX SoC updates for 4.16
From: Arnd Bergmann @ 2018-01-05 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-2-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> ----------------------------------------------------------------
> i.MX SoC updates for 4.16:
> - Drop power saving status checking from MMDC driver probe function,
> since there is nothing really depending on power saving being
> enabled.
> - Clean up unused imx3 pm definitions.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/5] i.MX drivers updates for 4.16
From: Arnd Bergmann @ 2018-01-05 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-1-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-drivers-4.16
>
> for you to fetch changes up to cfabb7921ccbede2968e5049d433ba3d0e0950af:
>
> soc: imx: gpc: Add i.MX6SX PCI power domain (2017-12-26 16:26:46 +0800)
>
> ----------------------------------------------------------------
> i.MX drivers update for 4.16:
> - Update i.MX GPC driver to support PCI power domain of i.MX6SX SoC.
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2 1/2] TI DaVinci SoC support updates for v4.16
From: Arnd Bergmann @ 2018-01-05 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105145248.1994-1-nsekhar@ti.com>
On Fri, Jan 5, 2018 at 3:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.16/soc-v2
>
> for you to fetch changes up to 23bbeaef90ab7607d03428bbb708efe44f43c761:
>
> ARM: davinci: constify gpio_led (2018-01-05 19:28:41 +0530)
>
> ----------------------------------------------------------------
> DaVinci SoC updates consisting of non-critical bug fixes including constifying
> data structures, removal of unnecessary newlines from gpio labels and code
> simplification.
>
> Also a defconfig update for DaVinci, enabling support for USB network adaptors.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.16
From: Arnd Bergmann @ 2018-01-05 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-5-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
>
> for you to fetch changes up to 189114b47b1cfcc5da02db9bcafebd2042aa7ab8:
>
> ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2017-12-26 17:04:13 +0800)
>
> ----------------------------------------------------------------
> i.MX defconfig updates for 4.16:
> - Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
> - Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
> - Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
> bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
>
> ----------------------------------------------------------------
> Dong Aisheng (1):
> ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT
This commit looks a bit fishy, as it does multiple things:
- add multitouch support
- move options around in the file that did not change
- drop some options (AEABI, CMA, SOC_CAMERA_OV2640,
SERIAL_DEV_CTRL_TTYPORT) for unknown reasons.
Cleaning up is fine, but please don't mix that with functional changes.
It's also fine to add multiple options at once in one patch, but when
you use 'make savedefconfig', please check each option that
gets dropped, some options might have gained new dependencies
or got renamed but are still needed here.
Finally, it might be good to check if the newly added options should
also be added to multi_v7_defconfig.
Not pulled for now, I'd suggest you resend without the 'savedefconfig'
cleanup, we can do that in a follow-up.
Arnd
^ permalink raw reply
* [PATCH 0/5] clk: read-only dividers and rate propagation fixup
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
A read-only divider may also have CLK_SET_RATE_PARENT flag set, in which
case it should propagate the requested rate to its parent, taking the
read-only divider value into account.
While this is done correctly in qcom's clk-regmap-divider, it is not in
the generic divider and lpc32xx.
Other drivers using divider_round_rate are not impacted because they are
using hard-coded flags without CLK_DIVIDER_READ_ONLY, so read-only
dividers does seems to be concern for them and rate propagation should
work as expected
Jerome Brunet (5):
clk: divider: read-only divider can propagate rate change
clk: lpc32xx: read-only divider can propagate rate change
clk: divider: add divider_ro_round_rate helper
clk: lpc32xx: use divider_ro_round_rate helper
clk: qcom: use divider_ro_round_rate helper
drivers/clk/clk-divider.c | 35 +++++++++++++++++++++++++++++------
drivers/clk/nxp/clk-lpc32xx.c | 15 ++++++++-------
drivers/clk/qcom/clk-regmap-divider.c | 19 ++++++-------------
include/linux/clk-provider.h | 15 +++++++++++++++
4 files changed, 58 insertions(+), 26 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH 1/5] clk: divider: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
register shall be left un-touched, but it does not mean the clock
should stop rate propagation if CLK_SET_RATE_PARENT is set
This is properly handled in qcom clk-regmap-divider but it was not in
the generic divider
Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/clk-divider.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index b49942b9fe50..a851d3e04c7f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -348,6 +348,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct clk_divider *divider = to_clk_divider(hw);
+ struct clk_hw *hw_parent = clk_hw_get_parent(hw);
int bestdiv;
/* if read only, just return current value */
@@ -356,6 +357,15 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
bestdiv &= div_mask(divider->width);
bestdiv = _get_div(divider->table, bestdiv, divider->flags,
divider->width);
+
+ /* Even a read-only clock can propagate a rate change */
+ if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
+ if (!hw_parent)
+ return -EINVAL;
+
+ *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
+ }
+
return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
}
--
2.14.3
^ permalink raw reply related
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
register shall be left un-touched, but it does not mean the clock
should stop rate propagation if CLK_SET_RATE_PARENT is set
This properly handled in qcom clk-regmap-divider but it was not in the
lpc32xx divider
Fixes: f7c82a60ba26 ("clk: lpc32xx: add common clock framework driver")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/nxp/clk-lpc32xx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index f5d815f577e0..729333766f97 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -963,6 +963,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
+ struct clk_hw *hw_parent = clk_hw_get_parent(hw);
unsigned int bestdiv;
/* if read only, just return current value */
@@ -972,6 +973,15 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
bestdiv &= div_mask(divider->width);
bestdiv = _get_div(divider->table, bestdiv, divider->flags,
divider->width);
+
+ /* Even a read-only clock can propagate a rate change */
+ if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
+ if (!hw_parent)
+ return -EINVAL;
+
+ *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
+ }
+
return DIV_ROUND_UP(*prate, bestdiv);
}
--
2.14.3
^ permalink raw reply related
* [PATCH 3/5] clk: divider: add divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
Like divider_round_rate, a couple a of driver are doing more or less
the same operation to round the rate of the divider when it is read-only.
We can factor this code so let's provide an helper function for this
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/clk-divider.c | 43 ++++++++++++++++++++++++++++---------------
include/linux/clk-provider.h | 15 +++++++++++++++
2 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index a851d3e04c7f..3eb2b27f3513 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -344,29 +344,42 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
}
EXPORT_SYMBOL_GPL(divider_round_rate_parent);
+long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+ unsigned long rate, unsigned long *prate,
+ const struct clk_div_table *table, u8 width,
+ unsigned long flags, unsigned int val)
+{
+ int div;
+
+ div = _get_div(table, val, flags, width);
+
+ /* Even a read-only clock can propagate a rate change */
+ if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
+ if (!parent)
+ return -EINVAL;
+
+ *prate = clk_hw_round_rate(parent, rate * div);
+ }
+
+ return DIV_ROUND_UP_ULL((u64)*prate, div);
+}
+EXPORT_SYMBOL_GPL(divider_ro_round_rate_parent);
+
+
static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct clk_divider *divider = to_clk_divider(hw);
- struct clk_hw *hw_parent = clk_hw_get_parent(hw);
- int bestdiv;
+ u32 val;
/* if read only, just return current value */
if (divider->flags & CLK_DIVIDER_READ_ONLY) {
- bestdiv = clk_readl(divider->reg) >> divider->shift;
- bestdiv &= div_mask(divider->width);
- bestdiv = _get_div(divider->table, bestdiv, divider->flags,
- divider->width);
-
- /* Even a read-only clock can propagate a rate change */
- if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
- if (!hw_parent)
- return -EINVAL;
-
- *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
- }
+ val = clk_readl(divider->reg) >> divider->shift;
+ val &= div_mask(divider->width);
- return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
+ return divider_ro_round_rate(hw, rate, prate, divider->table,
+ divider->width, divider->flags,
+ val);
}
return divider_round_rate(hw, rate, prate, divider->table,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 175a62a15619..eb2c3a035e98 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -417,6 +417,10 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
unsigned long rate, unsigned long *prate,
const struct clk_div_table *table,
u8 width, unsigned long flags);
+long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+ unsigned long rate, unsigned long *prate,
+ const struct clk_div_table *table, u8 width,
+ unsigned long flags, unsigned int val);
int divider_get_val(unsigned long rate, unsigned long parent_rate,
const struct clk_div_table *table, u8 width,
unsigned long flags);
@@ -772,6 +776,17 @@ static inline long divider_round_rate(struct clk_hw *hw, unsigned long rate,
rate, prate, table, width, flags);
}
+static inline long divider_ro_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate,
+ const struct clk_div_table *table,
+ u8 width, unsigned long flags,
+ unsigned int val)
+{
+ return divider_ro_round_rate_parent(hw, clk_hw_get_parent(hw),
+ rate, prate, table, width, flags,
+ val);
+}
+
/*
* FIXME clock api without lock protection
*/
--
2.14.3
^ permalink raw reply related
* [PATCH 4/5] clk: lpc32xx: use divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
There is now an helper function to round the rate when the
divider is read-only. Let's use it
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/nxp/clk-lpc32xx.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index 729333766f97..c20285e74b8e 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -963,26 +963,17 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
- struct clk_hw *hw_parent = clk_hw_get_parent(hw);
- unsigned int bestdiv;
+ unsigned int val;
/* if read only, just return current value */
if (divider->flags & CLK_DIVIDER_READ_ONLY) {
- regmap_read(clk_regmap, divider->reg, &bestdiv);
- bestdiv >>= divider->shift;
- bestdiv &= div_mask(divider->width);
- bestdiv = _get_div(divider->table, bestdiv, divider->flags,
- divider->width);
-
- /* Even a read-only clock can propagate a rate change */
- if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
- if (!hw_parent)
- return -EINVAL;
-
- *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
- }
+ regmap_read(clk_regmap, divider->reg, &val);
+ val >>= divider->shift;
+ val &= div_mask(divider->width);
- return DIV_ROUND_UP(*prate, bestdiv);
+ return divider_ro_round_rate(hw, rate, prate, divider->table,
+ divider->width, divider->flags,
+ bestdiv);
}
return divider_round_rate(hw, rate, prate, divider->table,
--
2.14.3
^ permalink raw reply related
* [PATCH 5/5] clk: qcom: use divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
There is now an helper function to round the rate when the
divider is read-only. Let's use it
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/qcom/clk-regmap-divider.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/qcom/clk-regmap-divider.c b/drivers/clk/qcom/clk-regmap-divider.c
index 4e9b8c2c8980..114e36b97255 100644
--- a/drivers/clk/qcom/clk-regmap-divider.c
+++ b/drivers/clk/qcom/clk-regmap-divider.c
@@ -28,22 +28,15 @@ static long div_round_ro_rate(struct clk_hw *hw, unsigned long rate,
{
struct clk_regmap_div *divider = to_clk_regmap_div(hw);
struct clk_regmap *clkr = ÷r->clkr;
- u32 div;
+ u32 val;
struct clk_hw *hw_parent = clk_hw_get_parent(hw);
- regmap_read(clkr->regmap, divider->reg, &div);
- div >>= divider->shift;
- div &= BIT(divider->width) - 1;
- div += 1;
-
- if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
- if (!hw_parent)
- return -EINVAL;
-
- *prate = clk_hw_round_rate(hw_parent, rate * div);
- }
+ regmap_read(clkr->regmap, divider->reg, &val);
+ val >>= divider->shift;
+ val &= BIT(divider->width) - 1;
- return DIV_ROUND_UP_ULL((u64)*prate, div);
+ return divider_ro_round_rate(hw, rate, prate, NULL, divider->width,
+ CLK_DIVIDER_ROUND_CLOSEST, val);
}
static long div_round_rate(struct clk_hw *hw, unsigned long rate,
--
2.14.3
^ permalink raw reply related
* [PATCH] imx6: fix pcie enumeration
From: Lorenzo Pieralisi @ 2018-01-05 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ebf30c78-b772-6214-f441-c86ae7fdba7e@ncentric.com>
On Fri, Jan 05, 2018 at 02:39:57PM +0100, Koen Vandeputte wrote:
>
>
> On 2018-01-05 13:32, Lorenzo Pieralisi wrote:
> >
> >> /* setup bus numbers */
> >> val = dw_pcie_readl_dbi
> >> val &= 0xff000000;
> >> val |= 0x00010100; <--- hardcoded today
> >> dw_pcie_writel_dbi
>
> >>I *think* I understand what's going on - the kernel takes the primary,
> >>secondary and subordinate values in the host bridge as valid in:
> >>
> >>pci_scan_bridge_extend()
> >>
> >>and given that pcibios_assign_all_busses() returns false (guess) it sets-up
> >>the bus hierarchy with a bus resource with subordinate number as read from
> >>PCI host bridge config space - which, given that it is 1 according to your
> >>explanation - this triggers the issue you reported.
> >>
> >>After commit a20c7f36bd3d the root bus resource is propagated down the
> >>hierarchy, hence the problem.
> >>
> >>So, in order to fix the issue I think the best way is to programme the
> >>root bridge in:
> >>
> >>drivers/pci/dwc/pci-designware-host.c
> >>
> >>but with the value coming from the root bus IORESOURCE_BUS resource,
> >>not hardcoding 0xff.
> >>
> >>I would kindly ask you to send logs with debug turned on in:
> >>
> >>drivers/pci/probe.c
> >>
> >>since I would like to check my understanding is correct.
> >>
> >>Please CC all dwc host maintainers since this has potential widespread
> >>impact.
> >>
> >>Thanks,
> >>Lorenzo
> Hi Lorenzo,
>
> This is exactly what I'm trying to explain:
>
> The host starts of with a (hardcoded today) subord of 1. [bits 16:23]
>
> Since commit a20c7f36bd3d, downstream devices cannot assign bus nr's
> higher than the subord of the upstream device.
> So in this case, scanning stops after the bridge as soon as bus 1 is
> assigned .. :)
There is one thing that I need to understand though. Before the commit
above, how would enumeration works given that the subordinate bus number
was set to 1 and that the kernel, AFAICS, does not overwrite it ?
Are you able to send me a log (enumeration with debugging enabled and
lspci) with the commit above reverted please ?
Thanks,
Lorenzo
> As other targets besides i.MX6 (layerscape, armada8k, ...) also use
> the same function to init PCIe, I believe those targets are also
> affected.
>
> I've tested here setting the PCI_PRIMARY_BUS register to 0x 00 ff 01
> 00? (ignored-subord-secbus-primbus), and the whole scanning works
> again.
> I fully agree that hardcoding is not the final fix, as this param
> can be defined in a DT.
>
>
> Fixing this, combined with the upstream commit exposing the error,
> fixes all following pci boot errors:
>
> ..
> [??? 0.466405] pci_bus 0000:05: [bus 05] partially hidden behind
> bridge 0000:01 [bus 01]
> ..
> [??? 0.466435] pci_bus 0000:02: busn_res: can not insert [bus 02-05]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.466454] pci_bus 0000:02: [bus 02-05] partially hidden behind
> bridge 0000:01 [bus 01]
> ..
>
>
> Watching the tree using lspci also shows that all primaries,
> secondaries and subords are perfectly logical as expected.
>
>
> Thanks,
>
> Koen
>
>
> Log showing the initial issue without any fixup:
>
>
> [??? 0.116673] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
> [??? 0.116692] OF: PCI:?? No bus range found for
> /soc/pcie at 0x01000000, using [bus 00-ff]
> [??? 0.116719] OF: PCI:??? IO 0x01f80000..0x01f8ffff -> 0x00000000
> [??? 0.116739] OF: PCI:?? MEM 0x01000000..0x01efffff -> 0x01000000
> [??? 0.337752] imx6q-pcie 1ffc000.pcie: link up
> [??? 0.337771] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
> [??? 0.337785] imx6q-pcie 1ffc000.pcie: link up
> [??? 0.337796] imx6q-pcie 1ffc000.pcie: Link up, Gen1
> [??? 0.338039] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
> [??? 0.338055] pci_bus 0000:00: root bus resource [bus 00-ff]
> [??? 0.338069] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
> [??? 0.338082] pci_bus 0000:00: root bus resource [mem
> 0x01000000-0x01efffff]
> [??? 0.338094] pci_bus 0000:00: scanning bus
> [??? 0.338127] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> [??? 0.338151] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [??? 0.338168] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> [??? 0.338204] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x4c
> [??? 0.338259] pci 0000:00:00.0: supports D1
> [??? 0.338267] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> [??? 0.338276] pci 0000:00:00.0: PME# disabled
> [??? 0.338512] pci_bus 0000:00: fixups for bus
> [??? 0.338525] PCI: bus0: Fast back to back transfers disabled
> [??? 0.338541] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
> [??? 0.338673] pci_bus 0000:01: scanning bus
> [??? 0.338773] pci 0000:01:00.0: [10b5:8604] type 01 class 0x060400
> [??? 0.338816] pci 0000:01:00.0: calling ventana_pciesw_early_fixup+0x0/0xa4
> [??? 0.467817] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0001ffff]
> [??? 0.467999] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x4c
> [??? 0.468467] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
> [??? 0.468491] pci 0000:01:00.0: PME# disabled
> [??? 0.468795] pci_bus 0000:01: fixups for bus
> [??? 0.468854] PCI: bus1: Fast back to back transfers disabled
> [??? 0.468877] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
> [??? 0.468886] pci 0000:01:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [??? 0.468939] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
> [??? 0.469265] pci_bus 0000:02: busn_res: can not insert [bus 02-01]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.469282] pci_bus 0000:02: scanning bus
> [??? 0.469554] pci_bus 0000:02: fixups for bus
> [??? 0.469559] PCI: bus2: Fast back to back transfers enabled
> [??? 0.469572] pci_bus 0000:02: bus scan returning with max=02
> [??? 0.469582] pci_bus 0000:02: busn_res: [bus 02-01] end is updated to 02
> [??? 0.469593] pci_bus 0000:02: busn_res: can not insert [bus 02]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.469615] pci_bus 0000:02: [bus 02] partially hidden behind
> bridge 0000:01 [bus 01]
> [??? 0.469636] pci_bus 0000:01: bus scan returning with max=02
> [??? 0.469643] pci 0000:00:00.0: bridge has subordinate 01 but max busn 02
> [??? 0.469661] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
> [??? 0.469671] pci_bus 0000:00: bus scan returning with max=01
> [??? 0.469791] pci 0000:00:00.0: fixup irq: got 298
> [??? 0.469800] pci 0000:00:00.0: assigning IRQ 298
> [??? 0.469849] pci 0000:01:00.0: fixup irq: got 298
> [??? 0.469856] pci 0000:01:00.0: assigning IRQ 298
> [??? 0.469946] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> [??? 0.469965] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> [??? 0.469980] pci 0000:00:00.0: BAR 6: assigned [mem
> 0x01200000-0x0120ffff pref]
> [??? 0.469997] pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x0111ffff]
> [??? 0.470026] pci 0000:01:00.0: PCI bridge to [bus 02]
> [??? 0.470108] pci 0000:00:00.0: PCI bridge to [bus 01]
> [??? 0.470121] pci 0000:00:00.0:?? bridge window [mem 0x01100000-0x011fffff]
> [??? 0.470381] pcieport 0000:00:00.0: Signaling PME through PCIe PME
> interrupt
> [??? 0.470397] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
> [??? 0.470412] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
> [??? 0.470660] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
> [??? 0.470788] pcieport 0000:01:00.0: enabling bus mastering
>
>
>
> [ Node 4 | node-4 ] lspci -tv
> -[0000:00]---00.0-[01]----00.0-[02]--
> [ Node 4 | node-4 ]
>
>
>
> [ Node 4 | node-4 ] lspci -v
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
> [Normal decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> ??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: 01100000-011fffff [size=1M]
> ??? Prefetchable memory behind bridge: None
> ??? [virtual] Expansion ROM at 01200000 [disabled] [size=64K]
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> ??? Capabilities: [70] Express Root Port (Slot-), MSI 00
> ??? Capabilities: [100] Advanced Error Reporting
> ??? Capabilities: [140] Virtual Channel
> ??? Kernel driver in use: pcieport
> lspci: Unable to load libkmod resources: error -12
>
> 01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01100000 (32-bit, non-prefetchable) [size=128K]
> ??? Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: None
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Upstream Port, MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [138] Power Budgeting <?>
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
> Len=0cc <?>
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
> [ Node 4 | node-4 ]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox