* Re: [PATCH -V3] mm: Move change_prot_numa outside CONFIG_ARCH_USES_NUMA_PROT_NONE
From: Mel Gorman @ 2013-12-06 11:30 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: riel, paulus, linuxppc-dev, linux-mm
In-Reply-To: <1386268702-30806-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Fri, Dec 06, 2013 at 12:08:22AM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> change_prot_numa should work even if _PAGE_NUMA != _PAGE_PROTNONE.
> On archs like ppc64 that don't use _PAGE_PROTNONE and also have
> a separate page table outside linux pagetable, we just need to
> make sure that when calling change_prot_numa we flush the
> hardware page table entry so that next page access result in a numa
> fault.
>
> We still need to make sure we use the numa faulting logic only
> when CONFIG_NUMA_BALANCING is set. This implies the migrate-on-fault
> (Lazy migration) via mbind will only work if CONFIG_NUMA_BALANCING
> is set.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
You're right on that there is no direct dependance on numa balancing and
use of prot_none. The BUILD_BUG_ON was to flag very clearly that arches
wanting to support automatic NUMA balancing must ensure such things as
o _PAGE_NUMA is defined
o setting _PAGE_NUMA traps a fault and the fault can be uniquely
identified as being a numa hinting fault
o that pte_present still returns true for pte_numa pages even though the
underlying present bit may be cleared. Otherwise operations like
following and copying ptes will get confused
o shortly, arches will also need to avoid taking references on pte_numa
pages in get_user_pages to account for hinting faults properly
I guess the _PAGE_NUMA parts will already be caught by other checks and
the rest will fall out during testing so it's ok to remove.
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* [PATCH] powernv: fix VFIO support with PHB3
From: Thadeu Lima de Souza Cascardo @ 2013-12-06 12:21 UTC (permalink / raw)
To: benh
Cc: shangw, aik, linux-kernel, paulus, Thadeu Lima de Souza Cascardo,
linuxppc-dev
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);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH V4 00/10] perf: New conditional branch filter
From: Arnaldo Carvalho de Melo @ 2013-12-06 13:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: mikey, ak, linux-kernel, eranian, linuxppc-dev, sukadev, mingo,
Anshuman Khandual
In-Reply-To: <1386218874.6009.7.camel@concordia>
Em Thu, Dec 05, 2013 at 03:47:54PM +1100, Michael Ellerman escreveu:
> On Wed, 2013-12-04 at 16:02 +0530, Anshuman Khandual wrote:
> > This patchset is the re-spin of the original branch stack sampling
> > patchset which introduced new PERF_SAMPLE_BRANCH_COND branch filter. This patchset
> > also enables SW based branch filtering support for book3s powerpc platforms which
> > have PMU HW backed branch stack sampling support.
> >
> > Summary of code changes in this patchset:
> >
> > (1) Introduces a new PERF_SAMPLE_BRANCH_COND branch filter
> > (2) Add the "cond" branch filter options in the "perf record" tool
> > (3) Enable PERF_SAMPLE_BRANCH_COND in X86 platforms
> > (4) Enable PERF_SAMPLE_BRANCH_COND in POWER8 platform
> > (5) Update the documentation regarding "perf record" tool
>
>
> Hi Arnaldo,
>
> Can you please take just patches 1-5 into the perf tree? And do you mind
> putting them in a topic branch so Benh can merge that.
This is mostly kernel code, I process the userspace ones, so I think either
Ingo or PeterZ should pick these, Ingo, Peter?
Only:
Subject: [PATCH V4 03/10] perf, tool: Conditional branch filter 'cond' added to perf record
Which is a one liner, touches tools/perf/, and I'm ok with it.
- Arnaldo
> The remaining patches are powerpc specific and still need some more review.
>
> cheers
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
From: Hong H. Pham @ 2013-12-06 16:15 UTC (permalink / raw)
To: Aneesh Kumar K.V, linux-rt-users, linuxppc-dev
Cc: Paul Mackerras, linux-stable
In-Reply-To: <874n6muuw4.fsf@linux.vnet.ibm.com>
Hi Aneesh,
On 12/06/2013 05:38 AM, Aneesh Kumar K.V wrote:
> can you also specifiy the config details here. ie, 4K page size functions
> are broken ?
My PPC64 config has SMP and 4K page size enabled. I re-tested with 64K page size,
and the problem is not present.
I have added a note that this problem affects only PPC32 and PPC64 SMP kernels.
On PPC64, the problem is limited to 4K page size.
> make it closer to what it was before,
>
> pgtable_page_dtor(table);
> pgtable_free_tlb(tlb, page_address(table), 0);
>
> This is what we had before
>
> -static inline void __pte_free_tlb(struct mmu_gather *tlb, struct page *ptepage,
> - unsigned long address)
> -{
> - tlb_flush_pgtable(tlb, address);
> - pgtable_page_dtor(ptepage);
> - pgtable_free_tlb(tlb, page_address(ptepage), 0);
> -}
>
>
> -aneesh
>
Done.
Thanks,
Hong
^ permalink raw reply
* [PATCH v2] powerpc: Fix PTE page address mismatch in pgtable ctor/dtor
From: Hong H. Pham @ 2013-12-06 16:17 UTC (permalink / raw)
To: linux-rt-users, linuxppc-dev
Cc: Paul Mackerras, Hong H. Pham, Aneesh Kumar K.V, linux-stable
In-Reply-To: <874n6muuw4.fsf@linux.vnet.ibm.com>
From: "Hong H. Pham" <hong.pham@windriver.com>
In pte_alloc_one(), pgtable_page_ctor() is passed an address that has
not been converted by page_address() to the newly allocated PTE page.
When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor()
with an address to the PTE page that has been converted by page_address().
The mismatch in the PTE's page address causes pgtable_page_dtor() to access
invalid memory, so resources for that PTE (such as the page lock) is not
properly cleaned up.
On PPC32, only SMP kernels are affected.
On PPC64, only SMP kernels with 4K page size are affected.
This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8
"powerpc: Move the pte free routines from common header".
On a preempt-rt kernel, a spinlock is dynamically allocated for each
PTE in pgtable_page_ctor(). When the PTE is freed, calling
pgtable_page_dtor() with a mismatched page address causes a memory leak,
as the pointer to the PTE's spinlock is bogus.
On mainline, there isn't any immediately obvious symptoms, but the
problem still exists here.
Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header"
Cc: Paul Mackerras <paulus@samba.org>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-stable <stable@vger.kernel.org> # v3.10+
Signed-off-by: Hong H. Pham <hong.pham@windriver.com>
---
arch/powerpc/include/asm/pgalloc-32.h | 6 ++----
arch/powerpc/include/asm/pgalloc-64.h | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/pgalloc-32.h b/arch/powerpc/include/asm/pgalloc-32.h
index 27b2386..b70ff06 100644
--- a/arch/powerpc/include/asm/pgalloc-32.h
+++ b/arch/powerpc/include/asm/pgalloc-32.h
@@ -84,10 +84,8 @@ static inline void pgtable_free_tlb(struct mmu_gather *tlb,
static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
unsigned long address)
{
- struct page *page = page_address(table);
-
tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(page);
- pgtable_free_tlb(tlb, page, 0);
+ pgtable_page_dtor(table);
+ pgtable_free_tlb(tlb, page_address(table);, 0);
}
#endif /* _ASM_POWERPC_PGALLOC_32_H */
diff --git a/arch/powerpc/include/asm/pgalloc-64.h b/arch/powerpc/include/asm/pgalloc-64.h
index f65e27b..256d6f8 100644
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -144,11 +144,9 @@ static inline void pgtable_free_tlb(struct mmu_gather *tlb,
static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t table,
unsigned long address)
{
- struct page *page = page_address(table);
-
tlb_flush_pgtable(tlb, address);
- pgtable_page_dtor(page);
- pgtable_free_tlb(tlb, page, 0);
+ pgtable_page_dtor(table);
+ pgtable_free_tlb(tlb, page_address(table), 0);
}
#else /* if CONFIG_PPC_64K_PAGES */
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH V4 04/10] x86, perf: Add conditional branch filtering support
From: Andi Kleen @ 2013-12-06 16:46 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mikey, linux-kernel, eranian, michael, linuxppc-dev, acme,
sukadev, mingo
In-Reply-To: <1386153162-11225-5-git-send-email-khandual@linux.vnet.ibm.com>
On Wed, Dec 04, 2013 at 04:02:36PM +0530, Anshuman Khandual wrote:
> This patch adds conditional branch filtering support,
> enabling it for PERF_SAMPLE_BRANCH_COND in perf branch
> stack sampling framework by utilizing an available
> software filter X86_BR_JCC.
Newer Intel CPUs a hardware filter too for "not a conditional
branch". I can look at implementing that.
The software option seems fine for now.
-Andi
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> Reviewed-by: Stephane Eranian <eranian@google.com>
> ---
> arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> index d82d155..9dd2459 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> @@ -384,6 +384,9 @@ static void intel_pmu_setup_sw_lbr_filter(struct perf_event *event)
> if (br_type & PERF_SAMPLE_BRANCH_NO_TX)
> mask |= X86_BR_NO_TX;
>
> + if (br_type & PERF_SAMPLE_BRANCH_COND)
> + mask |= X86_BR_JCC;
> +
> /*
> * stash actual user request into reg, it may
> * be used by fixup code for some CPU
> @@ -678,6 +681,7 @@ static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
> * NHM/WSM erratum: must include IND_JMP to capture IND_CALL
> */
> [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL | LBR_IND_JMP,
> + [PERF_SAMPLE_BRANCH_COND] = LBR_JCC,
> };
>
> static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
> @@ -689,6 +693,7 @@ static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
> [PERF_SAMPLE_BRANCH_ANY_CALL] = LBR_REL_CALL | LBR_IND_CALL
> | LBR_FAR,
> [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL,
> + [PERF_SAMPLE_BRANCH_COND] = LBR_JCC,
> };
>
> /* core */
> --
> 1.7.11.7
>
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Scott Wood @ 2013-12-06 18:59 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: <6A3DF150A5B70D4F9B66A25E3F7C888D07251EE4@039-SN2MPN1-012.039d.mgd.msft.net>
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.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Loading kernels over 8Mbytes without CONFIG_PIN_TLB
From: Scott Wood @ 2013-12-06 19:09 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20131127110406.6DC8E1A504F@localhost.localdomain>
On Wed, 2013-11-27 at 12:04 +0100, Christophe Leroy wrote:
> Today, the only way to load kernels whose size is greater than 8Mbytes is to
> activate CONFIG_PIN_TLB. Otherwise, the physical memory initially mapped is
> limited to 8Mbytes. This patch sets up 24 Mbytes of initial memory regardless
> of whether CONFIG_PIN_TLB is active or not. It allows to load "big" kernels
> (for instance when activating CONFIG_LOCKDEP_SUPPORT) without having
> to activate CONFIG_PIN_TLB.
So, what happens on boards with less than 24M memory present? Even if
you avoid explicitly referencing those addresses, what if there is a
speculative access -- or does 8xx not do that?
-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
* 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 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] 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 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 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: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 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 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
* [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
* 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
* 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
* 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 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 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 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 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
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