Hi All,
The SCSI cards work again. [1, 2]
Sorry for bothering you.
Thanks,
Christian
[1]
http://forum.hyperion-entertainment.com/viewtopic.php?f=58=49603=1adf9e6d558c136c1ad4ff15c44212ba#p49599
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205201
This is only used in pci-ioda.c so move it there and rename it to match.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 22 +-
arch/powerpc/platforms/powernv/pci.c | 20
arch/powerpc/platforms/powernv/pci.h |
pnv_pci_dma_dev_setup() does nothing but call the phb->dma_dev_setup()
callback, if one exists. That callback is only set for normal PCIe PHBs so
we can remove the layer of indirection and use the ioda version in
the pci_controller_ops.
Signed-off-by: Oliver O'Halloran
---
An ioda_pe for each VF is allocated in pnv_pci_sriov_enable() before the
pci_dev for the VF is created. We need to set the pe->pdev pointer at
some point after the pci_dev is created. Currently we do that in:
pcibios_bus_add_device()
pnv_pci_dma_dev_setup() (via phb->ops.dma_dev_setup)
The pnv_pci_dma_dev_setup() only does something when:
1) There PHB contains VFs, or
2) The PHB defines a dma_dev_setup() callback in the pnv_phb structure.
Neither is true for NPU PHBs so there's no reason to set the callback.
Reviewed-by: Alexey Kardashevskiy
Signed-off-by: Oliver O'Halloran
pcibios_bus_add_device() is the only caller of pcibios_setup_device().
Fold them together since there's no real reason to keep them separate.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/kernel/pci-common.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
Pulled out of my big series since these are fairly standalone changes
The series folds some single-use functions together and shovels around
some code so it lives in a more sensible location. No functional
changes.
Le 09/01/2020 à 21:07, Segher Boessenkool a écrit :
On Thu, Jan 09, 2020 at 05:52:34PM +, Christophe Leroy wrote:
Wondering why we get something so complicated/redundant for
vdso_read_begin()
static __always_inline u32 vdso_read_begin(const struct vdso_data *vd)
{
u32 seq;
Use FW_FEATURE_SVM to detect a secure guest (SVM). This would be
more efficient than calling mfmsr() frequently.
Suggested-by: Michael Ellerman
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/include/asm/firmware.h | 3 ++-
arch/powerpc/include/asm/svm.h| 6 +-
Ultravisor disables some CPU features like BHRB, EBB and PMU in
secure virtual machines (SVMs). Skip accessing those registers
in SVMs to avoid getting a Program Interrupt.
Signed-off-by: Sukadev Bhattiprolu
Acked-by: Madhavan Srinivasan
---
Changelog[v2]
- [Michael Ellerman] Optimize
On Thu, Jan 09, 2020 at 08:15:01AM +, Christophe Leroy wrote:
> This message leads to think that memory protection is not implemented
> for the said architecture, whereas absence of CONFIG_STRICT_KERNEL_RWX
> only means that memory protection has not been selected at
> compile time.
>
> Don't
In lmb_is_removable(), if a section is not present, it should continue to
test the rest sections in the block. But the current code fails to do so.
Signed-off-by: Pingfan Liu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
To: linuxppc-dev@lists.ozlabs.org
---
On 02/12/2019 12:59, Alexey Kardashevskiy wrote:
> Here is an attempt to support bigger DMA space for devices
> supporting DMA masks less than 59 bits (GPUs come into mind
> first). POWER9 PHBs have an option to map 2 windows at 0
> and select a windows based on DMA address being below or above
maddy [ma...@linux.ibm.com] wrote:
>
> > __init_PMU:
> > +#ifdef CONFIG_PPC_SVM
> > + /*
> > +* SVM's are restricted from accessing PMU, so skip.
> > +*/
> > + mfmsr r5
> > + rldicl r5, r5, 64-MSR_S_LG, 62
> > + cmpwi r5,1
> > + beq skip1
>
> I know all MMCR* are
On 1/7/20 2:45 PM, John Hubbard wrote:
> Hi,
>
> The "track FOLL_PIN pages" would have been the very next patch, but it is
> not included here because I'm still debugging a bug report from Leon.
> Let's get all of the prerequisite work (it's been reviewed) into the tree
> so that future reviews
On Thu, Jan 09, 2020 at 05:52:34PM +, Christophe Leroy wrote:
> Wondering why we get something so complicated/redundant for
> vdso_read_begin()
>
> static __always_inline u32 vdso_read_begin(const struct vdso_data *vd)
> {
> u32 seq;
>
> while ((seq = READ_ONCE(vd->seq)) & 1)
>
Wondering why we get something so complicated/redundant for
vdso_read_begin()
static __always_inline u32 vdso_read_begin(const struct vdso_data *vd)
{
u32 seq;
while ((seq = READ_ONCE(vd->seq)) & 1)
cpu_relax();
smp_rmb();
return seq;
}
6e0:
Le 02/01/2020 à 12:29, Arnd Bergmann a écrit :
On Mon, Dec 30, 2019 at 1:27 PM Arnd Bergmann wrote:
On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy
wrote:
+static __always_inline
+long clock_getres32_fallback(clockid_t _clkid, struct old_timespec32 *_ts)
+{
+ struct
Hi Thomas,
On 01/09/2020 02:05 PM, Thomas Gleixner wrote:
Christophe!
Christophe Leroy writes:
In do_hres(), I see:
cycles = __arch_get_hw_counter(vd->clock_mode);
ns = vdso_ts->nsec;
last = vd->cycle_last;
if
Le 03/12/2019 à 04:46, Alastair D'Silva a écrit :
From: Alastair D'Silva
ocxl_context_detach_all() is called from ocxl_function_close(), so
there is no reason to leave the contexts allocated, as the caller
can do nothing useful with them at that point.
This also has the side-effect of
Le 03/12/2019 à 04:46, Alastair D'Silva a écrit :
From: Alastair D'Silva
Add functions to map/unmap LPC memory
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 4 +++
drivers/misc/ocxl/core.c | 50 +++
Le 03/12/2019 à 04:46, Alastair D'Silva a écrit :
From: Alastair D'Silva
Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 10 ++
drivers/misc/ocxl/link.c | 60
Le 03/12/2019 à 04:46, Alastair D'Silva a écrit :
From: Alastair D'Silva
This patch adds platform support to map & release LPC memory.
Signed-off-by: Alastair D'Silva
---
It looks ok now, thanks
Acked-by: Frederic Barrat
arch/powerpc/include/asm/pnv-ocxl.h | 2 ++
Christophe!
Christophe Leroy writes:
> In do_hres(), I see:
>
> cycles = __arch_get_hw_counter(vd->clock_mode);
> ns = vdso_ts->nsec;
> last = vd->cycle_last;
> if (unlikely((s64)cycles < 0))
> return -1;
>
>
On Thu, Jan 09, 2020 at 02:27:25PM +0530, Abdul Haleem wrote:
> + CC Christoph Hellwig
The only thing this commit changed for the dma coherent case (which
ppc64 uses) is that we now look up the page to free by the DMA address
instead of the virtual address passed in. Which suggests this call
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote:
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
>
> Implementations of ioreadX() do not modify the memory under the
On 08.01.2020 19:07, Peter Zijlstra wrote:
> On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
>>
>> Open access to perf_events monitoring for CAP_SYS_PERFMON privileged
>> processes. For backward compatibility reasons access to perf_events
>> subsystem remains open for
Let PPC_UV depend only on DEVICE_PRIVATE which in turn
will satisfy all the other required dependencies
Fixes: 013a53f2d25a ("powerpc: Ultravisor: Add PPC_UV config option")
Reported-by: kbuild test robot
Signed-off-by: Bharata B Rao
---
arch/powerpc/Kconfig | 6 +-
1 file changed, 1
+ CC Christoph Hellwig
On Wed, 2020-01-08 at 18:48 +0530, Abdul Haleem wrote:
> Greeting's
>
> Kernel Oops on my powerpc system when unloading driver mpt3sas.
>
> Thanks Oliver for bisecting it to commit 3acac06 ("dma-mapping: merge
> the generic remapping helpers into dma-direct")
>
>
Hi
Am 08.01.20 um 21:05 schrieb Krzysztof Kozlowski:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be
At several places pmd pointer is retrieved through the same action:
pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
or
pmd = pmd_offset(pud_offset(pgd_offset_k(addr), addr), addr);
Refactor this by implementing two helpers pmd_ptr() and pmd_ptr_k()
This will
Commit 8d30c14cab30 ("powerpc/mm: Rework I$/D$ coherency (v3)") and
commit 90ac19a8b21b ("[POWERPC] Abolish iopa(), mm_ptov(),
io_block_mapping() from arch/powerpc") removed the use of get_pteptr()
outside of mm/pgtable_32.c
In mm/pgtable_32.c, the only user of get_pteptr() is change_page_attr()
This message leads to think that memory protection is not implemented
for the said architecture, whereas absence of CONFIG_STRICT_KERNEL_RWX
only means that memory protection has not been selected at
compile time.
Don't print this message when CONFIG_ARCH_HAS_STRICT_KERNEL_RWX is
selected by the
33 matches
Mail list logo
