* Re: [PATCH v6 14/17] net: can: mscan: adjust to common clock support for mpc512x
From: Anatolij Gustschin @ 2013-12-07 9:57 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Marc Kleine-Budde, linuxppc-dev, Wolfgang Grandegger, linux-can
In-Reply-To: <1385851897-23475-15-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:34 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> implement a .get_clock() callback for the MPC512x platform which uses
> the common clock infrastructure (eliminating direct access to the clock
> control registers from within the CAN network driver), and provide the
> corresponding .put_clock() callback to release resources after use
>
> acquire both the clock items for register access ("ipg") as well as for
> wire communication ("can")
>
> keep the previous implementation of MPC512x support in place during
> migration, this results in a readable diff of the change
>
> this change is neutral to the MPC5200 platform
>
> Cc: Wolfgang Grandegger <wg@grandegger.com>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> Cc: linux-can@vger.kernel.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/net/can/mscan/mpc5xxx_can.c | 179 +++++++++++++++++++++++++++++++++++
> 1 file changed, 179 insertions(+)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 13/17] [media] fsl-viu: adjust for OF based clock lookup
From: Anatolij Gustschin @ 2013-12-07 9:55 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: linux-media, linuxppc-dev, Mauro Carvalho Chehab
In-Reply-To: <1385851897-23475-14-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:33 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> after device tree based clock lookup became available, the VIU driver
> need no longer use the previous global "viu_clk" name, but should use
> the "ipg" clock name specific to the OF node
>
> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/media/platform/fsl-viu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 12/17] mtd: mpc5121_nfc: adjust for OF based clock lookup
From: Anatolij Gustschin @ 2013-12-07 9:55 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: David Woodhouse, linuxppc-dev, linux-mtd, Artem Bityutskiy
In-Reply-To: <1385851897-23475-13-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:32 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> after device tree based clock lookup became available, the NAND
> flash driver need no longer use the previous global "nfc_clk" name,
> but should use the "ipg" clock name specific to the OF node
>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Cc: linux-mtd@lists.infradead.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/mtd/nand/mpc5121_nfc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 11/17] USB: fsl-mph-dr-of: adjust for OF based clock lookup
From: Anatolij Gustschin @ 2013-12-07 9:53 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Greg Kroah-Hartman, linux-usb, linuxppc-dev
In-Reply-To: <1385851897-23475-12-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:31 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> after device tree based clock lookup became available, the peripheral
> driver need no longer construct clock names which include the component
> index -- remove the "usb%d_clk" template, always use "ipg" instead
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/usb/host/fsl-mph-dr-of.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 10/17] serial: mpc512x: setup the PSC FIFO clock as well
From: Anatolij Gustschin @ 2013-12-07 9:51 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Greg Kroah-Hartman, linuxppc-dev, linux-serial
In-Reply-To: <1385851897-23475-11-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:30 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> prepare and enable the FIFO clock upon PSC FIFO initialization,
> check for and propagage errors when enabling the PSC FIFO clock,
> disable and unprepare the FIFO clock upon PSC FIFO uninitialization
>
> devm_{get,put}_clk() doesn't apply here, as the SoC provides a
> single FIFO component which is shared among several PSC components,
> thus the FIFO isn't associated with a device (while the PSCs are)
>
> provide a fallback clock lookup approach in case the OF based clock
> lookup for the PSC FIFO fails, this allows for successful operation in
> the presence of an outdated device tree which lacks clock specs
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.cz>
> Cc: linux-serial@vger.kernel.org
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> # for v4
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> Greg, the addition since v4 is the clk_get_sys() call for the 'ipg'
> clock item (backwards compat for device trees w/o clock specs)
>
> ---
> drivers/tty/serial/mpc52xx_uart.c | 50 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 44 insertions(+), 6 deletions(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 09/17] serial: mpc512x: adjust for OF based clock lookup
From: Anatolij Gustschin @ 2013-12-07 9:49 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Greg Kroah-Hartman, linuxppc-dev, linux-serial
In-Reply-To: <1385851897-23475-10-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:29 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> after device tree based clock lookup became available, the peripheral
> driver need no longer construct clock names which include the PSC index,
> remove the "psc%d_mclk" template and unconditionally use 'mclk'
>
> acquire and release the "ipg" clock item for register access as well
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Jiri Slaby <jslaby@suse.cz>
> Cc: linux-serial@vger.kernel.org
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> # for v4
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> Greg, the difference since v4 of this patch is that v4 took the 'mclk'
> and 'ipg' clock items in reverse order, and thus potentially obfuscated
> the adjusted name for 'mclk' -- the updated version of the patch is
> identical in content but cleaner diff-wise
>
> ---
> drivers/tty/serial/mpc52xx_uart.c | 40 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 35 insertions(+), 5 deletions(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 08/17] spi: mpc512x: adjust to OF based clock lookup
From: Anatolij Gustschin @ 2013-12-07 9:46 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Mark Brown, linuxppc-dev, linux-spi
In-Reply-To: <1385851897-23475-9-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:28 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> after device tree based clock lookup became available, the peripheral
> driver need no longer construct clock names which include the PSC index,
> remove the "psc%d_mclk" template and unconditionally use 'mclk'
>
> acquire and release the 'ipg' clock item for register access as well
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: linux-spi@vger.kernel.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/spi/spi-mpc512x-psc.c | 26 ++++++++++++++++++--------
> 1 file changed, 18 insertions(+), 8 deletions(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 07/17] clk: mpc5xxx: switch to COMMON_CLK, retire PPC_CLOCK
From: Anatolij Gustschin @ 2013-12-07 9:42 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Scott Wood, Mike Turquette, linuxppc-dev
In-Reply-To: <1385851897-23475-8-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:27 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> the setup before the change was
> - arch/powerpc/Kconfig had the PPC_CLOCK option, off by default
> - depending on the PPC_CLOCK option the arch/powerpc/kernel/clock.c file
> was built, which implements the clk.h API but always returns -ENOSYS
> unless a platform registers specific callbacks
> - the MPC52xx platform selected PPC_CLOCK but did not register any
> callbacks, thus all clk.h API calls keep resulting in -ENOSYS errors
> (which is OK, all peripheral drivers deal with the situation)
> - the MPC512x platform selected PPC_CLOCK and registered specific
> callbacks implemented in arch/powerpc/platforms/512x/clock.c, thus
> provided real support for the clock API
> - no other powerpc platform did select PPC_CLOCK
>
> the situation after the change is
> - the MPC512x platform implements the COMMON_CLK interface, and thus the
> PPC_CLOCK approach in arch/powerpc/platforms/512x/clock.c has become
> obsolete
> - the MPC52xx platform still lacks genuine support for the clk.h API
> while this is not a change against the previous situation (the error
> code returned from COMMON_CLK stubs differs but every call still
> results in an error)
> - with all references gone, the arch/powerpc/kernel/clock.c wrapper and
> the PPC_CLOCK option have become obsolete, as did the clk_interface.h
> header file
>
> the switch from PPC_CLOCK to COMMON_CLK is done for all platforms within
> the same commit such that multiplatform kernels (the combination of 512x
> and 52xx within one executable) keep working
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/Kconfig | 5 -
> arch/powerpc/include/asm/clk_interface.h | 20 -
> arch/powerpc/kernel/Makefile | 1 -
> arch/powerpc/kernel/clock.c | 82 ----
> arch/powerpc/platforms/512x/Kconfig | 2 +-
> arch/powerpc/platforms/512x/Makefile | 1 -
> arch/powerpc/platforms/512x/clock.c | 754 ------------------------------
> arch/powerpc/platforms/52xx/Kconfig | 2 +-
> 8 files changed, 2 insertions(+), 865 deletions(-)
> delete mode 100644 arch/powerpc/include/asm/clk_interface.h
> delete mode 100644 arch/powerpc/kernel/clock.c
> delete mode 100644 arch/powerpc/platforms/512x/clock.c
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 06/17] dts: mpc512x: add clock specs for client lookups
From: Anatolij Gustschin @ 2013-12-07 9:41 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Mike Turquette, linuxppc-dev, Rob Herring, devicetree
In-Reply-To: <1385851897-23475-7-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:26 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> this addresses the client side of device tree based clock lookups
>
> add clock specifiers to the mbx, nfc, mscan, sdhc, i2c, axe, diu, viu,
> mdio, fec, usb, pata, psc, psc fifo, and pci nodes in the shared
> mpc5121.dtsi include
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: devicetree@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Reviewed-by: Mike Turquette <mturquette@linaro.org> # for v3: w/o bdlc, PSC ipg
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/boot/dts/mpc5121.dtsi | 95 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 05/17] clk: mpc512x: add backwards compat to the CCF code
From: Anatolij Gustschin @ 2013-12-07 9:40 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Mike Turquette, linuxppc-dev
In-Reply-To: <1385851897-23475-6-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:25 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> extend the recently added COMMON_CLK platform support for MPC512x such
> that it works with incomplete device tree data which lacks clock specs
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/platforms/512x/clock-commonclk.c | 173 ++++++++++++++++++++++++-
> 1 file changed, 172 insertions(+), 1 deletion(-)
moved node macro definitions out of the function body and applied
to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 04/17] clk: mpc512x: introduce COMMON_CLK for MPC512x (disabled)
From: Anatolij Gustschin @ 2013-12-07 9:37 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: Mike Turquette, linuxppc-dev
In-Reply-To: <1385851897-23475-5-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:24 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> this change implements a clock driver for the MPC512x PowerPC platform
> which follows the COMMON_CLK approach and uses common clock drivers
> shared with other platforms
>
> this driver implements the publicly announced set of clocks (those
> listed in the dt-bindings header file), as well as generates additional
> 'struct clk' items where the SoC hardware cannot easily get mapped to
> the common primitives (shared code) of the clock API, or requires
> "intermediate clock nodes" to represent clocks that have both gates and
> dividers
>
> the previous PPC_CLOCK implementation is kept in place and remains
> active for the moment, the newly introduced CCF clock driver will
> receive additional support for backwards compatibility in a subsequent
> patch before it gets enabled and will replace the PPC_CLOCK approach
>
> some of the clock items get pre-enabled in the clock driver to not have
> them automatically disabled by the underlying clock subsystem because of
> their being unused -- this approach is desirable because
> - some of the clocks are useful to have for diagnostics and information
> despite their not getting claimed by any drivers (CPU, internal and
> external RAM, internal busses, boot media)
> - some of the clocks aren't claimed by their peripheral drivers yet,
> either because of missing driver support or because device tree specs
> aren't available yet (but the workarounds will get removed as the
> drivers get adjusted and the device tree provides the clock specs)
>
> clkdev registration provides "alias names" for few clock items
> - to not break those peripheral drivers which encode their component
> index into the name that is used for clock lookup (UART, SPI, USB)
> - to not break those drivers which use names for the clock lookup which
> were encoded in the previous PPC_CLOCK implementation (NFC, VIU, CAN)
> this workaround will get removed as these drivers get adjusted after
> device tree based clock lookup has become available
>
> the COMMON_CLK implementation copes with device trees which lack an
> oscillator node (backwards compat), the REF clock is then derived from
> the IPS bus frequency and multiplier values fetched from hardware
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/platforms/512x/Makefile | 4 +-
> arch/powerpc/platforms/512x/clock-commonclk.c | 798 +++++++++++++++++++++++++
> include/linux/clk-provider.h | 16 +
> 3 files changed, 817 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 03/17] dts: mpc512x: add clock related device tree specs
From: Anatolij Gustschin @ 2013-12-07 9:34 UTC (permalink / raw)
To: Gerhard Sittig; +Cc: devicetree, linuxppc-dev, Rob Herring
In-Reply-To: <1385851897-23475-4-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:23 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> this addresses the clock driver aka provider's side of clocks
> - introduce a 'clocks' subtree with an 'osc' node for the crystal
> or oscillator SoC input (fixed frequency)
> - the 'clock@f00' clock-control-module node references the 'osc' for
> its input, and is another provider for all the clocks which the
> CCM component manages
> - prepare for future references to clocks from peripheral nodes
> by means of the <&clks ID> syntax and symbolic ID names which a
> header file provides
> - provide default values with 33MHz oscillator frequency in the
> common include (the 66MHz IPS bus already was there), and add
> override values for the ifm AC14xx board which deviates from
> the reference design (25MHz xtal, 80MHz IPS bus)
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Reviewed-by: Mike Turquette <mturquette@linaro.org> # for v3, before &osc
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> arch/powerpc/boot/dts/ac14xx.dts | 7 +++++++
> arch/powerpc/boot/dts/mpc5121.dtsi | 18 +++++++++++++++++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH v6 02/17] dts: mpc512x: introduce dt-bindings/clock/ header
From: Anatolij Gustschin @ 2013-12-07 9:32 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Mark Rutland, Mike Turquette, linuxppc-dev, Rob Herring,
devicetree
In-Reply-To: <1385851897-23475-3-git-send-email-gsi@denx.de>
On Sat, 30 Nov 2013 23:51:22 +0100
Gerhard Sittig <gsi@denx.de> wrote:
> introduce a dt-bindings/ header file for MPC512x clocks,
> providing symbolic identifiers for those SoC clocks which
> clients will reference from their device tree nodes
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: devicetree@vger.kernel.org
> Reviewed-by: Mike Turquette <mturquette@linaro.org> # for v3: w/o bdlc, PSC ipg
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> include/dt-bindings/clock/mpc512x-clock.h | 69 +++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 include/dt-bindings/clock/mpc512x-clock.h
applied to next. Thanks!
Anatolij
^ permalink raw reply
* Re: [PATCH] powernv: fix VFIO support with PHB3
From: Alexey Kardashevskiy @ 2013-12-07 0:58 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, benh
Cc: linuxppc-dev, paulus, shangw, linux-kernel
In-Reply-To: <1386332504-18339-1-git-send-email-cascardo@linux.vnet.ibm.com>
On 12/06/2013 11:21 PM, Thadeu Lima de Souza Cascardo wrote:
> I have recently found out that no iommu_groups could be found under
> /sys/ on a P8. That prevents PCI passthrough from working.
>
> During my investigation, I found out there seems to be a missing
> iommu_register_group for PHB3. The following patch seems to fix the
> problem. After applying it, I see iommu_groups under
> /sys/kernel/iommu_groups/, and can also bind vfio-pci to an adapter,
> which gives me a device at /dev/vfio/.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 084cdfa..2c6d173 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -720,6 +720,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
> tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE;
> }
> iommu_init_table(tbl, phb->hose->node);
> + iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
>
> if (pe->pdev)
> set_iommu_table_base(&pe->pdev->dev, tbl);
This does not seem absolutely right - normally set_iommu_table_base() is
replaced with set_iommu_table_base_and_group() or you will not see some
devices in a group and this may make VFIO unhappy.
But - if every single device gets assigned to some group, then we can push
this to Frobisher and let people test in on power8.
--
Alexey
^ permalink raw reply
* questions: second of the 2 pcie controllers does not scan the bus.
From: Ruchika @ 2013-12-07 0:48 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <1386376365.7375.209.camel@snotra.buserror.net>
Hi,
I am working with an p4080 based board. I am trying to get 2 PCIE
controllers probed properly.
In uboot I have no problems scanning and discovering what is connected
to both controllers/PCI bridges.
For both PCIE1/2 uboot sets up the Primary, secondary and Subordinate
bus numbers to 0,1,1 respectively.
When linux boots up and probes the controllers, PCIE1 is probed and the
bridge scanned properly but PCIE2 is probed at the bridge but not
attempted a scan.
I see this message
"pci 0001:02:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
"
I updated uboot to set the secondary and subordinate numbers to 2 (left
the primary number to 0) and a subsequent kernel boot scanned the bus
for PCIE2 successfully.
I found these numbers to be very critical since the device tree blob
(bus-range) for pci is also based off these.
I'd like to get a good fix rather than the uboot hack and get better
understanding of the problem. If there are any pointers someone could
provide it would be awesome.
Thank you
Regards
Ruchika
^ permalink raw reply
* [PATCH] powerpc/44x: fix ocm_block allocation
From: Ilia Mirkin @ 2013-12-07 0:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Vinh Nguyen Huu Tuong, Ilia Mirkin
Allocate enough memory for the ocm_block structure, not just a pointer
to it.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
---
I have neither the hardware to test nor the toolchain to even build-test
this. However this seems like a fairly obvious fix (and I have to wonder how
this ever worked at all). Found with spatch.
Actually further investigation makes it seem like this function is never
called, perhaps it should just be removed? If it is kept around though, would
be nice to apply this patch so that tools don't trip over this wrong code.
arch/powerpc/sysdev/ppc4xx_ocm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c
index b7c4345..85d9e37 100644
--- a/arch/powerpc/sysdev/ppc4xx_ocm.c
+++ b/arch/powerpc/sysdev/ppc4xx_ocm.c
@@ -339,7 +339,7 @@ void *ppc4xx_ocm_alloc(phys_addr_t *phys, int size, int align,
if (IS_ERR_VALUE(offset))
continue;
- ocm_blk = kzalloc(sizeof(struct ocm_block *), GFP_KERNEL);
+ ocm_blk = kzalloc(sizeof(struct ocm_block), GFP_KERNEL);
if (!ocm_blk) {
printk(KERN_ERR "PPC4XX OCM: could not allocate ocm block");
rh_free(ocm_reg->rh, offset);
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
From: Scott Wood @ 2013-12-07 0:32 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Liu Yu, linuxppc-dev, linux-kernel, Shan Hai
In-Reply-To: <Pine.LNX.4.64.1311230053360.12354@digraph.polyomino.org.uk>
On Sat, 2013-11-23 at 01:22 +0000, Joseph S. Myers wrote:
> On Fri, 22 Nov 2013, Scott Wood wrote:
>
> > This sounds like an incompatible change to userspace API. What about
> > older glibc? What about user code that directly manipulates these bits
> > rather than going through libc, or uses a libc other than glibc? Where
> > is this API requirement documented?
>
> The previous EGLIBC port, and the uClibc code copied from it, is
> fundamentally broken as regards any use of prctl for floating-point
> exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its prctl
> calls (and did various worse things, such as passing a pointer when prctl
> expected an integer). If you avoid anything where prctl is used, the
> clearing of sticky bits still means it will never give anything
> approximating correct exception semantics with existing kernels. I don't
> believe the patch makes things any worse for existing code that doesn't
> try to inform the kernel of changes to sticky bits - such code may get
> incorrect exceptions in some cases, but it would have done so anyway in
> other cases.
OK -- please mention this in the changelog.
> This is the best API I could come up with to fix the fundamentally broken
> nature of what came before, taking into account that in many cases a prctl
> call is already needed along with userspace manipulation of exception
> bits. I'm not aware of any kernel documentation where this sort of
> subarchitecture-specific API detail is documented. (The API also includes
> such things as needing to leave the spefscr trap-enable bits set and use
> prctl to control whether SIGFPE results from exceptions.)
I don't know of a formal place for it, but there should at least be a
code comment somewhere.
> > I think the impact of this could be reduced by using this mechanism only
> > to clear bits, rather than set them. That is, if the exception bit is
> > unset, don't set it just because it's set in spefscr_last -- but if it's
> > not set in spefscr_last, and the emulation code doesn't want to set it,
> > then clear it.
>
> It should already be the case in this patch that if a bit is clear in
> spefscr, and set in spefscr_last (i.e. userspace did not inform the kernel
> of clearing the bit, and no traps since then have resulted in the kernel
> noticing it was cleared), it won't get set unless the emulation code wants
> to set it. The sole place spefscr_last is read is in the statement
> "__FPU_FPSCR &= ~(FP_EX_INVALID | FP_EX_UNDERFLOW) |
> current->thread.spefscr_last;" - if the bit is already clear in spefscr,
> this statement has no effect on it.
OK -- I must have misread it before.
-Scott
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Scott Wood @ 2013-12-07 0:22 UTC (permalink / raw)
To: Alex Williamson
Cc: linux-pci@vger.kernel.org, agraf@suse.de, Yoder Stuart-B08248,
iommu@lists.linux-foundation.org, bhelgaas@google.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1386358226.25738.506.camel@ul30vt.home>
On Fri, 2013-12-06 at 12:30 -0700, Alex Williamson wrote:
> On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote:
> > On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, December 06, 2013 5:52 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Alex Williamson; linux-pci@vger.kernel.org; agraf@suse.de; Yoder Stuart-
> > > > B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > > > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> > > >
> > > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Bhushan Bharat-R65777
> > > > > > Sent: Wednesday, November 27, 2013 9:39 PM
> > > > > > To: 'Alex Williamson'
> > > > > > Cc: Wood Scott-B07421; linux-pci@vger.kernel.org; agraf@suse.de;
> > > > > > Yoder Stuart- B08248; iommu@lists.linux-foundation.org;
> > > > > > bhelgaas@google.com; linuxppc- dev@lists.ozlabs.org;
> > > > > > linux-kernel@vger.kernel.org
> > > > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > > > IOMMU (PAMU)
> > > > > >
> > > > > > If we just provide the size of MSI bank to userspace then userspace
> > > > > > cannot do anything wrong.
> > > > >
> > > > > So userspace does not know address, so it cannot mmap and cause any
> > > > interference by directly reading/writing.
> > > >
> > > > That's security through obscurity... Couldn't the malicious user find out the
> > > > address via other means, such as experimentation on another system over which
> > > > they have full control? What would happen if the user reads from their device's
> > > > PCI config space? Or gets the information via some back door in the PCI device
> > > > they own? Or pokes throughout the address space looking for something that
> > > > generates an interrupt to its own device?
> > >
> > > So how to solve this problem, Any suggestion ?
> > >
> > > We have to map one window in PAMU for MSIs and a malicious user can ask
> > > its device to do DMA to MSI window region with any pair of address and
> > > data, which can lead to unexpected MSIs in system?
> >
> > I don't think there are any solutions other than to limit each bank to
> > one user, unless the admin turns some knob that says they're OK with the
> > partial loss of isolation.
>
> Even if the admin does opt-in to an allow_unsafe_interrupts options, it
> should still be reasonably difficult for one guest to interfere with the
> other. I don't think we want to rely on the blind luck of making the
> full MSI bank accessible to multiple guests and hoping they don't step
> on each other. That probably means that vfio needs to manage the space
> rather than the guest. Thanks,
Yes, the MSIs within a given bank would be allocated by the host kernel
in any case (presumably by the MSI driver, not VFIO itself). This is
just about what happens if the MSI page is written to outside of the
normal mechanism.
-Scott
^ permalink raw reply
* Re: [PATCH RFC v4 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2013-12-06 20:41 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Arnd Bergmann, Vinod Koul, Gerhard Sittig, Alexander Popov,
Dan Williams, Anatolij Gustschin, linuxppc-dev,
devicetree-discuss
In-Reply-To: <52A234F5.9030300@metafoo.de>
2013/12/7 Lars-Peter Clausen <lars@metafoo.de>:
> On 12/06/2013 09:27 PM, Alexander Popov wrote:
>>
>> 2013/10/6 Gerhard Sittig <gsi@denx.de>:
>> * struct dma_slave_config - dma slave channel runtime config
>> * @direction: whether the data shall go in or out on this slave
>> * channel, right now. DMA_TO_DEVICE and DMA_FROM_DEVICE are
>> * legal values, DMA_BIDIRECTIONAL is not acceptable since we
>> * need to differentiate source and target addresses.
>> ...
>> struct dma_slave_config {
>> enum dma_transfer_direction direction;
>> ...
>> };
>>
>> The comment above the definition is obsolete, isn't it?
>
>
> Yes, the comment seems to be out of date. Care to send a patch fixing it?
Yes, I will prepare and send the patch.
Thanks
Alexander
^ permalink raw reply
* Re: [PATCH RFC v4 2/5] dma: mpc512x: add support for peripheral transfers
From: Lars-Peter Clausen @ 2013-12-06 20:35 UTC (permalink / raw)
To: Alexander Popov
Cc: Arnd Bergmann, Vinod Koul, Gerhard Sittig, Dan Williams,
Anatolij Gustschin, linuxppc-dev, devicetree-discuss
In-Reply-To: <CAF0T0X6XhHk5qhwk=Kzu_YvMNduZaMqNxGWRyyeNP8LWzDJziw@mail.gmail.com>
On 12/06/2013 09:27 PM, Alexander Popov wrote:
> 2013/10/6 Gerhard Sittig <gsi@denx.de>:
>> On Thu, Oct 03, 2013 at 18:06 +0400, Alexander Popov wrote:
>>> +
>>> + spin_lock_irqsave(&mchan->lock, flags);
>>> +
>>> + if (cfg->direction == DMA_DEV_TO_MEM) {
>>
>> Note that cfg->direction is of a different type than
>> DMA_DEV_TO_MEM (of different type than the 'direction' parameter
>> in the preparation routine) -- it's mere coincidence that the
>> numeric values happen to match at the moment.
>
> Gerhard, it seems to me that this code is correct.
> Cite from dmaengine.h:
>
> * struct dma_slave_config - dma slave channel runtime config
> * @direction: whether the data shall go in or out on this slave
> * channel, right now. DMA_TO_DEVICE and DMA_FROM_DEVICE are
> * legal values, DMA_BIDIRECTIONAL is not acceptable since we
> * need to differentiate source and target addresses.
> ...
> struct dma_slave_config {
> enum dma_transfer_direction direction;
> ...
> };
>
> The comment above the definition is obsolete, isn't it?
Yes, the comment seems to be out of date. Care to send a patch fixing it?
- Lars
^ permalink raw reply
* Re: [PATCH RFC v4 2/5] dma: mpc512x: add support for peripheral transfers
From: Alexander Popov @ 2013-12-06 20:27 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Alexander Popov,
devicetree-discuss, linuxppc-dev
In-Reply-To: <20131006111038.GN14747@book.gsilab.sittig.org>
2013/10/6 Gerhard Sittig <gsi@denx.de>:
> On Thu, Oct 03, 2013 at 18:06 +0400, Alexander Popov wrote:
>> +
>> + spin_lock_irqsave(&mchan->lock, flags);
>> +
>> + if (cfg->direction == DMA_DEV_TO_MEM) {
>
> Note that cfg->direction is of a different type than
> DMA_DEV_TO_MEM (of different type than the 'direction' parameter
> in the preparation routine) -- it's mere coincidence that the
> numeric values happen to match at the moment.
Gerhard, it seems to me that this code is correct.
Cite from dmaengine.h:
* struct dma_slave_config - dma slave channel runtime config
* @direction: whether the data shall go in or out on this slave
* channel, right now. DMA_TO_DEVICE and DMA_FROM_DEVICE are
* legal values, DMA_BIDIRECTIONAL is not acceptable since we
* need to differentiate source and target addresses.
...
struct dma_slave_config {
enum dma_transfer_direction direction;
...
};
The comment above the definition is obsolete, isn't it?
Thanks
Alexander
^ permalink raw reply
* Re: [PATCH] watchdog: mpc8xxx_wdt: MPC8xx is HW enabled
From: Scott Wood @ 2013-12-06 19:35 UTC (permalink / raw)
To: Wolfgang Denk
Cc: linux-watchdog, linux-kernel, Wim Van Sebroeck, linuxppc-dev,
Guenter Roeck
In-Reply-To: <20131202061418.05A11380BFE@gemini.denx.de>
On Mon, 2013-12-02 at 07:14 +0100, Wolfgang Denk wrote:
> Dear Guenter,
>
> In message <529B9152.9090106@roeck-us.net> you wrote:
> > On 11/30/2013 07:45 AM, Christophe Leroy wrote:
> > > MPC8xx watchdog is enabled at startup by HW.
> > > If the bootloader disables it, it cannot be reenabled.
> >
> > Is that true for all variants of 8xx, especially for 823 ? I am a bit concerned
> > about breaking compatibility with some chips ... assuming there was a reason
> > for not setting this flag originally.
>
> This is correct, and applies for all variants of the MPC8xx, including
> the MPC823 / MPC823E. From the UM:
>
> "The software watchdog timer can be disabled or its timeout
> period can be changed in the SYPCR. Once the SYPCR is written,
> it cannot be written again until a system reset."
>
> Actually this is the only correct behaviour. Any watchdog that can be
> disabled by software is not worth it's name, and unsuitable for any
> kind of aplications where security / reliability are required.
An optional locked state is a good thing, but making that the only way
the watchdog can function can render the watchdog unusable in systems
that need to go into low power states (unless the low power state
supresses the watchdog). And then there's broken hybrid things like the
booke watchdog, where you can't disable the watchdog reset action once
configured, but you can change the timeout to be effectively infinite
(which we've used as a workaround when entering low power states).
-Scott
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Alex Williamson @ 2013-12-06 19:30 UTC (permalink / raw)
To: Scott Wood
Cc: linux-pci@vger.kernel.org, agraf@suse.de, Yoder Stuart-B08248,
Bharat Bhushan, iommu@lists.linux-foundation.org,
bhelgaas@google.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1386356393.7375.118.camel@snotra.buserror.net>
On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote:
> On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Friday, December 06, 2013 5:52 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Alex Williamson; linux-pci@vger.kernel.org; agraf@suse.de; Yoder Stuart-
> > > B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> > >
> > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Wednesday, November 27, 2013 9:39 PM
> > > > > To: 'Alex Williamson'
> > > > > Cc: Wood Scott-B07421; linux-pci@vger.kernel.org; agraf@suse.de;
> > > > > Yoder Stuart- B08248; iommu@lists.linux-foundation.org;
> > > > > bhelgaas@google.com; linuxppc- dev@lists.ozlabs.org;
> > > > > linux-kernel@vger.kernel.org
> > > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > > IOMMU (PAMU)
> > > > >
> > > > > If we just provide the size of MSI bank to userspace then userspace
> > > > > cannot do anything wrong.
> > > >
> > > > So userspace does not know address, so it cannot mmap and cause any
> > > interference by directly reading/writing.
> > >
> > > That's security through obscurity... Couldn't the malicious user find out the
> > > address via other means, such as experimentation on another system over which
> > > they have full control? What would happen if the user reads from their device's
> > > PCI config space? Or gets the information via some back door in the PCI device
> > > they own? Or pokes throughout the address space looking for something that
> > > generates an interrupt to its own device?
> >
> > So how to solve this problem, Any suggestion ?
> >
> > We have to map one window in PAMU for MSIs and a malicious user can ask
> > its device to do DMA to MSI window region with any pair of address and
> > data, which can lead to unexpected MSIs in system?
>
> I don't think there are any solutions other than to limit each bank to
> one user, unless the admin turns some knob that says they're OK with the
> partial loss of isolation.
Even if the admin does opt-in to an allow_unsafe_interrupts options, it
should still be reasonably difficult for one guest to interfere with the
other. I don't think we want to rely on the blind luck of making the
full MSI bank accessible to multiple guests and hoping they don't step
on each other. That probably means that vfio needs to manage the space
rather than the guest. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Scott Wood @ 2013-12-06 19:25 UTC (permalink / raw)
To: Bharat Bhushan
Cc: linux-pci@vger.kernel.org, agraf@suse.de,
iommu@lists.linux-foundation.org, Yoder Stuart-B08248,
Alex Williamson, bhelgaas@google.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D07251EFF@039-SN2MPN1-012.039d.mgd.msft.net>
On Thu, 2013-12-05 at 22:17 -0600, Bharat Bhushan wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, December 06, 2013 5:31 AM
> > To: Bhushan Bharat-R65777
> > Cc: Alex Williamson; linux-pci@vger.kernel.org; agraf@suse.de; Yoder Stuart-
> > B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> >
> > On Sun, 2013-11-24 at 23:33 -0600, Bharat Bhushan wrote:
> > >
> > > > -----Original Message-----
> > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > Sent: Friday, November 22, 2013 2:31 AM
> > > > To: Wood Scott-B07421
> > > > Cc: Bhushan Bharat-R65777; linux-pci@vger.kernel.org; agraf@suse.de;
> > > > Yoder Stuart-B08248; iommu@lists.linux-foundation.org;
> > > > bhelgaas@google.com; linuxppc- dev@lists.ozlabs.org;
> > > > linux-kernel@vger.kernel.org
> > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > IOMMU (PAMU)
> > > >
> > > > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote:
> > > > > They can interfere.
> > >
> > > Want to be sure of how they can interfere?
> >
> > If more than one VFIO user shares the same MSI group, one of the users can send
> > MSIs to another user, by using the wrong interrupt within the bank. Unexpected
> > MSIs could cause misbehavior or denial of service.
> >
> > > >> With this hardware, the only way to prevent that
> > > > > is to make sure that a bank is not shared by multiple protection contexts.
> > > > > For some of our users, though, I believe preventing this is less
> > > > > important than the performance benefit.
> > >
> > > So should we let this patch series in without protection?
> >
> > No, there should be some sort of opt-in mechanism similar to IOMMU-less VFIO --
> > but not the same exact one, since one is a much more serious loss of isolation
> > than the other.
>
> Can you please elaborate "opt-in mechanism"?
The system should be secure by default. If the administrator wants to
relax protection in order to accomplish some functionality, that should
require an explicit request such as a write to a sysfs file.
> > > > I think we need some sort of ownership model around the msi banks then.
> > > > Otherwise there's nothing preventing another userspace from
> > > > attempting an MSI based attack on other users, or perhaps even on
> > > > the host. VFIO can't allow that. Thanks,
> > >
> > > We have very few (3 MSI bank on most of chips), so we can not assign
> > > one to each userspace.
> >
> > That depends on how many users there are.
>
> What I think we can do is:
> - Reserve one MSI region for host. Host will not share MSI region with Guest.
> - For upto 2 Guest (MAX msi with host - 1) give then separate MSI sub regions
> - Additional Guest will share MSI region with other guest.
>
> Any better suggestion are most welcome.
If the administrator does not opt into this partial loss of isolation,
then once you run out of MSI groups, new users should not be able to set
up MSIs.
-Scott
^ permalink raw reply
* Re: [PATCH] DTS: DMA: Fix DMA3 interrupts
From: Scott Wood @ 2013-12-06 19:21 UTC (permalink / raw)
To: hongbo.zhang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1385712446-28221-1-git-send-email-hongbo.zhang@freescale.com>
On Fri, 2013-11-29 at 16:07 +0800, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> MPIC registers for internal interrupts is non-continous in address, any
> internal interrupt number greater than 159 should be added (16+208) to work.
> 16 is due to external interrupts as usual, 208 is due to the non-continous MPIC
> register space.
> Tested on T4240 rev2 with SRIO2 disabled.
>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/elo3-dma-2.dtsi | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
The FSL MPIC binding should be updated to point out how this works.
Technically it's not a change to the binding itself, since it's defined
in terms of register offset, but the explanatory text says "So interrupt
0 is at offset 0x0, interrupt 1 is at offset 0x20, and so on." which is
not accurate for these new high interrupt numbers.
-Scott
^ 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