1. Change v4l2 from get_user_pages() to pin_user_pages().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/media/v4l2-
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Jan Kara
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers
Convert infiniband to use the new pin_user_pages*() calls.
Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.
The new pin_u
On Thu, Nov 21, 2019 at 04:20:08AM +0100, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. F
On 11/11/19 at 01:31pm, Bhupesh Sharma wrote:
> Changes since v3:
>
> - v3 can be seen here:
> http://lists.infradead.org/pipermail/kexec/2019-March/022590.html
> - Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo
> instead of PTRS_PER_PGD.
> - Added a new
On Thu, 21 Nov 2019 at 15:21, Greg Kroah-Hartman
wrote:
>
> On Thu, Nov 21, 2019 at 04:20:08AM +0100, Krzysztof Kozlowski wrote:
> > Adjust indentation from spaces to tab (+optional two spaces) as in
> > coding style with command like:
> > $ sed -e 's/^/\t/' -i */Kconfig
> >
> > Sign
On Thu, Nov 21, 2019 at 03:22:27PM +0800, Krzysztof Kozlowski wrote:
> On Thu, 21 Nov 2019 at 15:21, Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Nov 21, 2019 at 04:20:08AM +0100, Krzysztof Kozlowski wrote:
> > > Adjust indentation from spaces to tab (+optional two spaces) as in
> > > coding style
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
> /*
> * DMA addressing mode.
> *
> * 0 : 32 bit addressing for all chips.
> * 1 : 40 bit addressing when supported by chip.
> * 2 : 64 bit addressing when supported by chip,
> * limited to 16 segments of 4 GB -> 64
On Tue, Nov 19, 2019 at 05:17:03PM +, Robin Murphy wrote:
> TBH I can't see it being a massive problem even if the DMA patch, driver
> and DTS patch went entirely separately via the respective DMA, PCI, and
> arm-soc trees in the same cycle. Bisecting over a merge window is a big
> enough pa
Robin, does this mean you ACK this series for the powerpc use case?
Alexey and other ppc folks: can you take a look?
> +#ifdef CONFIG_PCI_IOV
> + struct pnv_ioda_pe *pe;
> +
> + /* Fix the VF pdn PE number */
> + if (pdev->is_virtfn) {
> + list_for_each_entry(pe, &phb->ioda.pe_list, list) {
> + if (pe->rid == ((pdev->bus->number << 8) |
> + (pdev
On Wed, Nov 20, 2019 at 12:28:19PM +1100, Oliver O'Halloran wrote:
> Move this out of the PHB's dma_dev_setup() callback and into the
> ppc_md.pcibios_fixup_iov callback. This ensures that the VF PE's
> pdev pointer is always valid for the whole time the device is
> added the bus.
>
> This isn't s
On Wed, Nov 20, 2019 at 12:28:44PM +1100, Oliver O'Halloran wrote:
> Use the helper to look up the pnv_ioda_pe for the device we're configuring DMA
> for. In the VF case there's no need set pdn->pe_number since nothing looks at
> it any more.
>
> Signed-off-by: Oliver O'Halloran
> ---
> arch/pow
On Wed, Nov 20, 2019 at 11:13:32PM -0800, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there
Looks good,
Reviewed-by: Christoph Hellwig
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
I'd love to see code size change stats for an allyesconfig on this
commit.
On Wed, Nov 20, 2019 at 11:13:31PM -0800, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
Looks fine, but why not fold this into the patch using the flags.
Also you can use up your full 73 chars per lin
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Nov 20, 2019 at 11:13:37PM -0800, John Hubbard wrote:
> And get rid of the mmap_sem calls, as part of that. Note
> that get_user_pages_fast() will, if necessary, fall back to
> __gup_longterm_unlocked(), which takes the mmap_sem as needed.
>
> Reviewed-by: Jan Kara
> Reviewed-by: Jason Gu
On Wed, Nov 20, 2019 at 11:13:36PM -0800, John Hubbard wrote:
> +static int pin_goldfish_pages(unsigned long first_page,
> + unsigned long last_page,
> + unsigned int last_page_size,
> + int is_write,
> +
On Wed, Nov 20, 2019 at 11:13:38PM -0800, John Hubbard wrote:
> After DMA is complete, and the device and CPU caches are synchronized,
> it's still required to mark the CPU pages as dirty, if the data was
> coming from the device. However, this driver was just issuing a
> bare put_page() call, with
Should this be two patches, one for th core infrastructure and one for
the user? These changes also look like another candidate to pre-load.
On 11/21/19 12:06 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:31PM -0800, John Hubbard wrote:
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Looks fine, but why not fold this into the patch using the flags.
On 11/21/19 12:03 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:32PM -0800, John Hubbard wrote:
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the sam
On 11/21/19 12:08 AM, Christoph Hellwig wrote:
On Wed, Nov 20, 2019 at 11:13:36PM -0800, John Hubbard wrote:
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+
On 11/21/19 12:10 AM, Christoph Hellwig wrote:
Should this be two patches, one for th core infrastructure and one for
the user? These changes also look like another candidate to pre-load.
OK, I'll split them up.
thanks,
--
John Hubbard
NVIDIA
On 11/21/19 12:05 AM, Christoph Hellwig wrote:
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
I'd love to see code size change stats for an allyesconfig on this
commit.
Right, I'm running t
On Thu, 2019-11-21 at 08:31 +0100, Christoph Hellwig wrote:
> On Tue, Nov 19, 2019 at 05:17:03PM +, Robin Murphy wrote:
> > TBH I can't see it being a massive problem even if the DMA patch, driver
> > and DTS patch went entirely separately via the respective DMA, PCI, and
> > arm-soc trees in
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.
Wi
On Wed 20-11-19 23:13:47, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may b
On Thu 21-11-19 00:29:59, John Hubbard wrote:
> On 11/21/19 12:03 AM, Christoph Hellwig wrote:
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the reviews!
On Thu 21-11-19 00:29:59, John Hubbard wrote:
> >
> > Otherwise this looks fine and might be a worthwhile cleanup to feed
> > Andrew for 5.5 independent of the gut of the changes.
> >
> > Reviewed-by: Christoph Hellwig
> >
>
> Thanks for the reviews! Say, it sounds like your view here is that
On Wed, Nov 20, 2019 at 10:49 PM Ben Hutchings
wrote:
> On Wed, 2019-11-20 at 20:35 +0100, Arnd Bergmann wrote:
> > On Wed, Nov 20, 2019 at 8:13 PM Ben Hutchings
> > wrote:
> > > On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann wrote:
> > > > On little-endian 32-bit application running on 64-bit
On Thu, Nov 21, 2019 at 05:14:45PM +1100, Michael Ellerman wrote:
> Christophe Leroy writes:
> That breaks 64-bit with GCC9:
>
> arch/powerpc/kernel/irq.c: In function 'do_IRQ':
> arch/powerpc/kernel/irq.c:650:2: error: PIC register clobbered by 'r2' in
> 'asm'
> 650 | asm volatile(
>
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when supported by chip.
* 2 : 64 bit addressing when supported by
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when sup
On Thu, 2019-11-14 at 15:43 -0300, Leonardo Bras wrote:
> > If the kvm_put_kvm() you've moved actually caused the last
> > reference
> > to
> > be dropped that would mean that our caller had passed us a kvm
> > struct
> > without holding a reference to it, and that would be a bug in our
> > caller.
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style. This fixes various indentation mixups (seven spaces,
tab+one space, etc).
Signed-off-by: Krzysztof Kozlowski
---
drivers/net/Kconfig | 64 +--
drivers/net/caif/Kconfig
Adjust indentation from seven spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/tty/Kconfig | 28 ++--
drivers/tty/hvc/Kconfig | 28 ++--
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing
This is the linux part of the work to use the PCI hotplug framework to
control an opencapi card so that it can be reset and re-read after
flashing a new FPGA image. The changes required in skiboot are now
upstream. On an old skiboot, this series will do nothing.
A virtual PCI slot is created for t
The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was required. However, the pci_dev
pointer was later removed from the pci_dn structure, but the reference
was kept for the npu device.
See commit 902bdc57451c ("powerpc/powernv/idoa: Remove unnec
Protect the PHB's list of PE. Probably not needed as long as it was
populated during PHB creation, but it feels right and will become
required once we can add/remove opencapi devices on hotplug.
Reviewed-by: Andrew Donnellan
Signed-off-by: Frederic Barrat
---
Changelog:
v2: no change
arch/pow
With hotplug, an opencapi device can now go away. It needs to be
released, mostly to clean up its PE state. We were previously not
defining any device callback. We can reuse the standard PCI release
callback, it does a bit too much for an opencapi device, but it's
harmless, and only needs minor tun
On powernv, when removing a device through hotplug, the following
warning is logged:
Invalid refcount <.> on <...>
It may be incorrect, the refcount may be set to a higher value than 1
and be valid. of_detach_node() can drop more than one reference. As it
doesn't seem trivial to assert the c
The driver only allows to disable a slot in the POPULATED
state. However, if an error occurs while enabling the slot, say
because the link couldn't be trained, then the POPULATED state may not
be reached, yet the power state of the slot is on. So allow to disable
a slot in the REGISTERED state. Rem
The PE for an opencapi device was set as part of a late PHB fixup
operation, when creating the PHB. To use the PCI hotplug framework,
this is not going to work, as the PHB stays the same, it's only the
devices underneath which are updated. For regular PCI devices, it is
done as part of the reconfig
The PCI hotplug framework is used to update the devices when a new
image is written to the FPGA.
Reviewed-by: Alastair D'Silva
Reviewed-by: Andrew Donnellan
Signed-off-by: Frederic Barrat
---
Changelog:
v2: no change
drivers/misc/ocxl/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
Add the opencapi PHBs to the list of PHBs being scanned to look for
slots.
Signed-off-by: Frederic Barrat
---
Changelog:
v2:
- fix unregistration (Andrew)
drivers/pci/hotplug/pnv_php.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug
When changing the slot state, if opal hits an error and tells as such
in the asynchronous reply, the warning "Wrong msg" is logged, which is
rather confusing. Instead we can reuse the better message which is
already used when we couldn't submit the asynchronous opal request
initially.
Reviewed-by:
Unlike real PCI slots, opencapi slots are directly associated to
the (virtual) opencapi PHB, there's no intermediate bridge. So when
looking for a slot ID, we must start the search from the device node
itself and not its parent.
Also, the slot ID is not attached to a specific bdfn, so let's build
An opencapi slot doesn't have an associated bridge device. It's not
needed for operation, but any warning is displayed through pci_warn()
which uses the pci_dev struct of the assocated bridge device. So wrap
those warning so that a different trace mechanism can be used if it's
an opencapi slot.
Re
On Wed, Nov 20, 2019 at 11:43 PM Ben Hutchings
wrote:
>
> On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
> [...]
> > --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> > +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> > @@ -15,10 +15,8 @@
> > /* Offset for the low 32-bit part of a field
On Wed, Nov 20, 2019 at 11:49 PM Ben Hutchings
wrote:
>
> On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
> [...]
> > --- a/arch/x86/include/uapi/asm/sembuf.h
> > +++ b/arch/x86/include/uapi/asm/sembuf.h
> > @@ -21,9 +21,9 @@ struct semid64_ds {
> > unsigned long sem_ctime; /*
On Thu, Nov 21, 2019 at 12:07:46AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 20, 2019 at 11:13:37PM -0800, John Hubbard wrote:
> > And get rid of the mmap_sem calls, as part of that. Note
> > that get_user_pages_fast() will, if necessary, fall back to
> > __gup_longterm_unlocked(), which takes
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> Using a mask to represent bus DMA constraints has a set of limitations.
> The biggest one being it can only hold a power of two (minus one). The
> DMA mapping code is already aware of this and treats dev->bus_dma_mask
> as a
On Thu, 2019-11-21 at 16:24 +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> > Using a mask to represent bus DMA constraints has a set of limitations.
> > The biggest one being it can only hold a power of two (minus one). The
> > DMA mappin
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
> > Using a mask to represent bus DMA constraints has a set of limitations.
> > The biggest one being it can only hold a power of two (minus one). The
> > DMA
On 21/11/2019 3:26 pm, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only ho
On Thu, 2019-11-21 at 11:02 +0100, Arnd Bergmann wrote:
> On Wed, Nov 20, 2019 at 10:49 PM Ben Hutchings
> wrote:
> > On Wed, 2019-11-20 at 20:35 +0100, Arnd Bergmann wrote:
> > > On Wed, Nov 20, 2019 at 8:13 PM Ben Hutchings
> > > wrote:
> > > > On Fri, 2019-11-08 at 21:34 +0100, Arnd Bergmann w
On Thu, Nov 21, 2019 at 03:55:39PM +, Robin Murphy wrote:
> Hmm, there's no functional dependency though, is there? AFAICS it's
> essentially just a context conflict. Is it worth simply dropping (or
> postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or
> perhaps even cross-
Arnd Bergmann a écrit :
On Wed, Nov 20, 2019 at 11:43 PM Ben Hutchings
wrote:
On Fri, 2019-11-08 at 22:07 +0100, Arnd Bergmann wrote:
[...]
> --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> @@ -15,10 +15,8 @@
> /* Offset for the low 32-bit
Am 21.11.19 um 14:33 schrieb Robin Murphy:
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA add
On 21/11/2019 7:34 am, Christoph Hellwig wrote:
Robin, does this mean you ACK this series for the powerpc use case?
Yeah, I think we've nailed down sufficient justification now for having
a generalised flag, so at that point it makes every bit of sense to
convert PPC's private equivalent.
R
On Thu, Nov 21, 2019 at 05:02:17PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2019 at 03:55:39PM +, Robin Murphy wrote:
> > Hmm, there's no functional dependency though, is there? AFAICS it's
> > essentially just a context conflict. Is it worth simply dropping (or
> > postponing) the l
On Thu, Nov 21, 2019 at 12:57 AM John Hubbard wrote:
>
> On 11/21/19 12:05 AM, Christoph Hellwig wrote:
> > So while this looks correct and I still really don't see the major
> > benefit of the new code organization, especially as it bloats all
> > put_page callers.
> >
> > I'd love to see code si
On 21/11/2019 9:26 am, Nicolas Saenz Julienne wrote:
Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is alre
> On Sep 4, 2019, at 11:55 PM, Michael Ellerman wrote:
>
> Bart Van Assche writes:
>> On 8/30/19 2:13 PM, Qian Cai wrote:
>>> https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config
>>>
>>> Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would
>>> generate
>
On Thu, Nov 21, 2019 at 04:53:48PM +, Will Deacon wrote:
> Please go ahead and pull in our for-next/zone-dma branch if you need it.
> We're not going to rebase it, and I suspect we won't even be queueing
> anything else there at this stage in the game.
Ok. I've pulled it in and will wait with
On Thu, Nov 21, 2019 at 05:07:54PM +, Robin Murphy wrote:
> ^^ super-nit only because I can't not see my editor currently highlighting
> the typo: "accessible"
>
> Regardless of that though,
>
> Reviewed-by: Robin Murphy
Applied for real now with that typo fixed and on top of the pulled in
a
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
> I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
> attached)
>
> We have to wait to Rolands test results with his SCSI PCI card. I tested it
> today but my TV card doesn't work with this patch.
I think w
On 21. Nov 2019, at 19:02, Christoph Hellwig wrote:
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote:
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested it
today but my TV
From: Krzysztof Kozlowski
Date: Thu, 21 Nov 2019 21:28:28 +0800
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style. This fixes various indentation mixups (seven spaces,
> tab+one space, etc).
>
> Signed-off-by: Krzysztof Kozlowski
Applied to net-next.
On 11/21/19 1:49 AM, Jan Kara wrote:
On Thu 21-11-19 00:29:59, John Hubbard wrote:
On 11/21/19 12:03 AM, Christoph Hellwig wrote:
Otherwise this looks fine and might be a worthwhile cleanup to feed
Andrew for 5.5 independent of the gut of the changes.
Reviewed-by: Christoph Hellwig
Thanks
On 11/21/19 1:35 PM, Alex Williamson wrote:
On Wed, 20 Nov 2019 23:13:39 -0800
John Hubbard wrote:
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding
On 11/21/19 8:59 AM, Dan Williams wrote:
On Thu, Nov 21, 2019 at 12:57 AM John Hubbard wrote:
On 11/21/19 12:05 AM, Christoph Hellwig wrote:
So while this looks correct and I still really don't see the major
benefit of the new code organization, especially as it bloats all
put_page callers.
On Wed, 20 Nov 2019 23:13:39 -0800
John Hubbard wrote:
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote
Christophe Leroy writes:
> __get_datapage() is only a few instructions to retrieve the
> address of the page where the kernel stores data to the VDSO.
>
> By inlining this function into its users, a bl/blr pair and
> a mflr/mtlr pair is avoided, plus a few reg moves.
>
> The improvement is noticea
On 11/21/19 1:54 AM, Jan Kara wrote:
On Thu 21-11-19 00:29:59, John Hubbard wrote:
Otherwise this looks fine and might be a worthwhile cleanup to feed
Andrew for 5.5 independent of the gut of the changes.
Reviewed-by: Christoph Hellwig
Thanks for the reviews! Say, it sounds like your view
Hi
My hs400 series patches for ls1028 need do any changes?
Regards,
Yinbo Zhu.
-Original Message-
From: Yinbo Zhu
Sent: 2019年8月14日 15:27
To: Rob Herring ; Mark Rutland ;
Catalin Marinas ; Will Deacon ;
Adrian Hunter ; Ulf Hansson ;
Leo Li ; Claudiu Manoil ; Amit Jain
(aj) ; Y.b
On 22/11/19 12:49 am, Frederic Barrat wrote:
Unlike real PCI slots, opencapi slots are directly associated to
the (virtual) opencapi PHB, there's no intermediate bridge. So when
looking for a slot ID, we must start the search from the device node
itself and not its parent.
Also, the slot ID is n
On 22/11/19 12:49 am, Frederic Barrat wrote:
Add the opencapi PHBs to the list of PHBs being scanned to look for
slots.
Signed-off-by: Frederic Barrat
Reviewed-by: Andrew Donnellan
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Find the VF index based on the BDFN of the device rather than using a cached
> value in the pci_dn. This is probably slower than looking up the cached value
> in the pci_dn, but it's done infrequently (only in the EEH recovery path) and
> it's just
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> Switch the eeh_ops->{read|write}_config methods to take an eeh_dev structure
> rather than a pci_dn structure to specify the target device. This removes a
> lot of the uses of pci_dn in both the EEH core and in the platform EEH
> support.
>
> Sign
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> We use the pci_dn to retrieve the domain, bus, device, and function numbers
> for
> an EEH device. We now have that in the eeh_dev so covert the various printk()s
> we have around the place to source that information from the eeh_dev.
>
> Signed-
On 22/11/19 12:49 am, Frederic Barrat wrote:
With hotplug, an opencapi device can now go away. It needs to be
released, mostly to clean up its PE state. We were previously not
defining any device callback. We can reuse the standard PCI release
callback, it does a bit too much for an opencapi devi
On 20/11/2019 12:28, Oliver O'Halloran wrote:
> The EEH core has a concept of "early probe" and "late probe." When the
> EEH_PROBE_MODE_DEVTREE flag is set (i.e pseries) we call the eeh_ops->probe()
> function in eeh_add_device_early() so the eeh_dev state is initialised based
> on
> the pci_dn
From: Christophe Leroy
[ Upstream commit 32c8c4c621897199e690760c2d57054f8b84b6e6 ]
mfsrin() takes segment num from bits 31-28 (IBM bits 0-3).
Signed-off-by: Christophe Leroy
[mpe: Clarify bit numbering]
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/powerpc/xmon/xmon.c
From: Christophe Leroy
[ Upstream commit e93ba1b7eb5b188c749052df7af1c90821c5f320 ]
This patch fixes the loop in p_block_mapped() and v_block_mapped()
to scan the entire bat_addrs[] array.
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
---
arch/po
From: Madhavan Srinivasan
[ Upstream commit 2d46d4877b1afd14059393a48bdb8ce27955174c ]
Raw event code has couple of fields "unit" and "cache" in it, to capture
the "unit" to monitor for a given pmcxsel and cache reload qualifier to
program in MMCR1.
isa207_get_constraint() refers "unit" field t
From: Joel Stanley
[ Upstream commit 72e7bcc2cdf82bf03caaa5e6c9b0134c2fc2ee7d ]
When building for ppc32 with clang these flags are unsupported:
-ffixed-r2 and -mmultiple
llvm's lib/Target/PowerPC/PPCRegisterInfo.cpp marks r2 as reserved on
when building for SVR4ABI and !ppc64:
// The SVR4
From: Christophe Leroy
[ Upstream commit b18f0ae92b0a1db565c3e505fa87b6971ad3b641 ]
This patch fixes early DEBUG messages in prom.c:
- Use %px instead of %p to see the addresses
- Cast memblock_phys_mem_size() with (unsigned long long) to
avoid build failure when phys_addr_t is not 64 bits.
Sig
From: Christophe Leroy
[ Upstream commit 49a502ea23bf9dec47f8f3c3960909ff409cd1bb ]
As several other arches including x86, this patch makes it explicit
that a bad page fault is a NULL pointer dereference when the fault
address is lower than PAGE_SIZE
In the mean time, this page makes all bad_pa
From: Benjamin Herrenschmidt
[ Upstream commit 3cfb9ebe906b51f2942b1e251009bb251efd2ba6 ]
The bamboo dts has a bug: it uses a non-naturally aligned range
for PCI memory space. This isnt' supported by the code, thus
causing PCI to break on this system.
This is due to the fact that while the chip
From: Alexey Kardashevskiy
[ Upstream commit c20577014f85f36d4e137d3d52a1f61225b4a3d2 ]
The current implementation of the OPAL_PCI_EEH_FREEZE_STATUS call in
skiboot's NPU driver does not touch the pci_error_type parameter so
it might have garbage but the powernv code analyzes it nevertheless.
T
From: Christophe Leroy
[ Upstream commit 0deae39cec6dab3a66794f3e9e83ca4dc30080f1 ]
When the watchdog timer is set in interrupt mode, it causes a
machine check when it times out. The purpose of this mode is to
ease debugging, not to crash the kernel and reboot the machine.
This patch implements
From: Michael Ellerman
[ Upstream commit 47918bc68b7427e961035949cc1501a864578a69 ]
In update_lmb_associativity_index() we lookup dr_node using
of_find_node_by_path() which takes a reference for us. In the
non-error case we forget to drop the reference. Note that
find_aa_index() does modify prop
From: Benjamin Herrenschmidt
[ Upstream commit 505a314fb28ce122091691c51426fa85c084e115 ]
HMIs will crash the kernel due to
BRANCH_LINK_TO_FAR(hmi_exception_realmode)
Calling into the OPD instead of the actual code.
Fixes: 2337d207288f ("powerpc/64: CONFIG_RELOCATABLE support for hmi
From: Wen Yang
[ Upstream commit 40752b3eae29f8ca2378e978a02bd6dbeeb06d16 ]
This patch fixes potential double frees if register_hdlc_device() fails.
Signed-off-by: Wen Yang
Reviewed-by: Peng Hao
CC: Zhao Qiang
CC: "David S. Miller"
CC: net...@vger.kernel.org
CC: linuxppc-dev@lists.ozlabs.or
From: Gen Zhang
[ Upstream commit efa9ace68e487ddd29c2b4d6dd23242158f1f607 ]
In dlpar_parse_cc_property(), 'prop->name' is allocated by kstrdup().
kstrdup() may return NULL, so it should be checked and handle error.
And prop should be freed if 'prop->name' is NULL.
Signed-off-by: Gen Zhang
Sig
1 - 100 of 132 matches
Mail list logo
