On Mon, 04 Nov 2019 08:06:37 +0100,
youling 257 wrote:
>
> This patch cause oops on android mainline kernel about gadget audio_source.
> Androidx86 run on android mainline kernel.
>
> [ 385.104963] android_work: sent uevent USB_STATE=CONNECTED
> [ 385.109006] android_work: sent uevent USB_STATE=D
On 01/11/2019 17.27, Christophe Leroy wrote:
>
>
> Le 01/11/2019 à 13:42, Rasmus Villemoes a écrit :
>> The Soft UART hack is only needed for some PPC-based SOCs. To allow
>> building this driver for non-PPC, guard soft_uart_init() and its
>> helpers by CONFIG_PPC32, and use a no-op soft_uart_ini
On 01/11/2019 23.31, Leo Li wrote:
>
>
>> -Original Message-
>> From: Christophe Leroy
>> Sent: Friday, November 1, 2019 11:30 AM
>> To: Rasmus Villemoes ; Qiang Zhao
>> ; Leo Li
>> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
>> linux-ker...@vger.kernel.org;
On Tue, Oct 29, 2019 at 08:01:17PM -0500, Segher Boessenkool wrote:
> I am still not convinced the worse name is a better name, no :-) But if
> you don't want to do the work, and instead prefer the much smaller change,
> that is of course a fine decision. Thank you!
>
> (I would be happy with suc
On Mon, 04 Nov 2019 09:49:43 +0100,
Greg Kroah-Hartman wrote:
>
> On 11/4/19 9:32 AM, Greg Kroah-Hartman wrote:
> > On 11/4/19 9:27 AM, youling 257 wrote:
> > > This driver
> >
> https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/usb/gadget/function/f_audio_sour
Markus Elfring writes:
> From: Markus Elfring
> Date: Sun, 3 Nov 2019 13:23:13 +0100
>
> The field “owner” is set by the core.
> Thus delete an unneeded initialisation.
>
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
>
> Signed-off-by: Markus Elfring
> ---
> arch/powerpc/p
On Thursday, October 31, 2019 6:21:59 AM CET John Hubbard wrote:
> The following build warning occurred on powerpc 64-bit builds:
>
> drivers/cpufreq/powernv-cpufreq.c: In function 'init_chip_info':
> drivers/cpufreq/powernv-cpufreq.c:1070:1: warning: the frame size of
> 1040 bytes is larger than
On Fri, Nov 1, 2019 at 1:19 AM Masahiro Yamada
wrote:
>
> These are kernel source code even though they are just two-line wrappers.
>
> Files without explicit license information fall back to GPL-2.0-only,
> which is the project default.
That is true and these are kernel only files, but given the
FYI: The onboard SD card works also with the RC6 of kernel 5.4 with the
patch below.
-- Christian
On 23 October 2019 at 4:20pm, Christian Zigotzky wrote:
Hello,
The patch below works. I compiled the RC4 of kernel 5.4 with this patch today
and the onboard SD card works without any problems.
On Mon, Nov 4, 2019 at 5:08 AM Oliver O'Halloran wrote:
> Use "uname -a" to get the current kernel version, architecture.
Linux debian 5.3.8 #3 SMP Thu Oct 31 03:02:06 IST 2019 x86_64 GNU/Linux
> is a laptop it might be due to buggy power management,
yes this is an "asus vivobook"
> Can you pro
PCI devices can trigger interrupts via 4 physical/virtual lines known
as INTA, INTB, INTC or INTD. Due to interrupt swizzling it is often
required to describe the interrupt mapping in the device tree. Let's
avoid the existing magic numbers and replace them with a #define to
improve clarity.
Based
Replace magic numbers used to describe legacy PCI IRQ interrupts
with #define.
Signed-off-by: Andrew Murray
---
arch/powerpc/boot/dts/fsl/b4420qds.dts| 4 +-
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/b4860qds.dts| 4 +-
arch/powerpc/boo
Replace magic numbers used to describe legacy PCI IRQ interrupts
with #define.
Signed-off-by: Andrew Murray
---
arch/powerpc/boot/dts/bluestone.dts | 12 +++--
arch/powerpc/boot/dts/charon.dts | 12 +++--
arch/powerpc/boot/dts/digsy_mtc.dts | 12 +++--
arch/powerpc/boot/dts/
On Sun, Nov 03, 2019 at 01:17:56PM -0800, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
> Reviewed-by: Ira Weiny
> Cc: Kirill A. Shutemov
On Sun, Nov 03, 2019 at 01:17:57PM -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
On Sun, Nov 03, 2019 at 01:17:58PM -0800, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
>
> An upcoming patch will introduce a global pin_user_pages()
> function.
>
> Reviewed-by: Ira Weiny
> Signed-off-by: John
On Sun, Nov 03, 2019 at 01:18:00PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() varia
On Sun, Nov 03, 2019 at 01:18:03PM -0800, John Hubbard wrote:
> Convert process_vm_access to use the new pin_user_pages_remote()
> call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
> code that requires tracking of pinned pages.
>
> Also, release the pages via put_user_page*().
>
> A
On Sun, Nov 03, 2019 at 01:18:04PM -0800, John Hubbard wrote:
> Convert drm/via to use the new pin_user_pages_fast() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
>
> Reviewe
On Thu, Oct 31, 2019 at 04:36:28PM -0700, Ira Weiny wrote:
> On Wed, Oct 30, 2019 at 03:49:20PM -0700, John Hubbard wrote:
> > Convert drm/via to use the new pin_user_pages_fast() call, which sets
> > FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> > tracking of pinned pages, an
On 11/4/19 9:44 AM, Jerome Glisse wrote:
> On Sun, Nov 03, 2019 at 01:18:04PM -0800, John Hubbard wrote:
>> Convert drm/via to use the new pin_user_pages_fast() call, which sets
>> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
>> tracking of pinned pages, and therefore for any c
On Sun, Nov 03, 2019 at 01:18:07PM -0800, 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 FOL
On 11/4/19 9:33 AM, Jerome Glisse wrote:
...
>
> Few nitpick belows, nonetheless:
>
> Reviewed-by: Jérôme Glisse
> [...]
>> +
>> +CASE 3: ODP
>> +---
>> +(Mellanox/Infiniband On Demand Paging: the hardware supports
>> +replayable page faulting). There are GUP references to pages serving
On Mon, Nov 04, 2019 at 11:04:38AM -0800, John Hubbard wrote:
> On 11/4/19 9:33 AM, Jerome Glisse wrote:
> ...
> >
> > Few nitpick belows, nonetheless:
> >
> > Reviewed-by: Jérôme Glisse
> > [...]
> >> +
> >> +CASE 3: ODP
> >> +---
> >> +(Mellanox/Infiniband On Demand Paging: the hardwar
On 11/4/19 10:10 AM, Daniel Vetter wrote:
> On Thu, Oct 31, 2019 at 04:36:28PM -0700, Ira Weiny wrote:
>> On Wed, Oct 30, 2019 at 03:49:20PM -0700, John Hubbard wrote:
>>> Convert drm/via to use the new pin_user_pages_fast() call, which sets
>>> FOLL_PIN. Setting FOLL_PIN is now required for code t
On 11/4/19 11:18 AM, Jerome Glisse wrote:
> On Mon, Nov 04, 2019 at 11:04:38AM -0800, John Hubbard wrote:
>> On 11/4/19 9:33 AM, Jerome Glisse wrote:
>> ...
>>>
>>> Few nitpick belows, nonetheless:
>>>
>>> Reviewed-by: Jérôme Glisse
>>> [...]
+
+CASE 3: ODP
+---
+(Mella
hello ,
> > Can you provide the full dmesg and the output of lspci -vv?
> typical dmesg and lspci -vv is attached
new lspci -vv related attached
this time it is "sudo lspci -vv"
--
software engineer
rajagiri school of engineering and technology
00:00.0 Host bridge: Intel Corporation Xeon E3-120
On Mon, Nov 04, 2019 at 01:32:53PM +1100, Alastair D'Silva wrote:
> When calling flush_icache_range with a size >4GB, we were masking
> off the upper 32 bits, so we would incorrectly flush a range smaller
> than intended.
>
> This patch replaces the 32 bit shifts with 64 bit ones, so that
> the fu
On Mon, Nov 04, 2019 at 11:30:32AM -0800, John Hubbard wrote:
> On 11/4/19 11:18 AM, Jerome Glisse wrote:
> > On Mon, Nov 04, 2019 at 11:04:38AM -0800, John Hubbard wrote:
> >> On 11/4/19 9:33 AM, Jerome Glisse wrote:
> >> ...
> >>>
> >>> Few nitpick belows, nonetheless:
> >>>
> >>> Reviewed-by: Jé
Jason, a question for you at the bottom.
On 11/4/19 11:52 AM, Jerome Glisse wrote:
...
>> CASE 3: ODP
>> ---
>> RDMA hardware with page faulting support. Here, a well-written driver doesn't
>
> CASE3: Hardware with page fault support
> ---
>
> Here, a
On Mon, Nov 04, 2019 at 12:09:05PM -0800, John Hubbard wrote:
> Note for Jason: the (a) or (b) items are talking about the vfio case, which is
> one of the two call sites that now use pin_longterm_pages_remote(), and the
> other one is infiniband:
>
> drivers/infiniband/core/umem_odp.c:646:
On Mon, Nov 04, 2019 at 12:09:05PM -0800, John Hubbard wrote:
> Jason, a question for you at the bottom.
>
> On 11/4/19 11:52 AM, Jerome Glisse wrote:
> ...
> >> CASE 3: ODP
> >> ---
> >> RDMA hardware with page faulting support. Here, a well-written driver
> >> doesn't
> >
> > CASE3: Ha
On Sun, Nov 03, 2019 at 01:18:02PM -0800, John Hubbard wrote:
> Convert infiniband to use the new wrapper calls, and stop
> explicitly setting FOLL_LONGTERM at the call sites.
>
> The new pin_longterm_*() calls replace get_user_pages*()
> calls, and set both FOLL_LONGTERM and a new FOLL_PIN
> flag
On Mon, Nov 04, 2019 at 03:31:53PM -0500, Jerome Glisse wrote:
> > Note for Jason: the (a) or (b) items are talking about the vfio case, which
> > is
> > one of the two call sites that now use pin_longterm_pages_remote(), and the
> > other one is infiniband:
> >
> > drivers/infiniband/core/umem_o
On 11/4/19 12:31 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 12:09:05PM -0800, John Hubbard wrote:
>
>> Note for Jason: the (a) or (b) items are talking about the vfio case, which
>> is
>> one of the two call sites that now use pin_longterm_pages_remote(), and the
>> other one is infinib
On 11/4/19 12:33 PM, Jason Gunthorpe wrote:
...
>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>> index 24244a2f68cc..c5a78d3e674b 100644
>> +++ b/drivers/infiniband/core/umem.c
>> @@ -272,11 +272,10 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
>> unsigne
On Mon, Nov 04, 2019 at 12:33:09PM -0800, David Rientjes wrote:
>
>
> On Sun, 3 Nov 2019, John Hubbard wrote:
>
> > Introduce pin_user_pages*() variations of get_user_pages*() calls,
> > and also pin_longterm_pages*() variations.
> >
> > These variants all set FOLL_PIN, which is also introduced
On Mon, Nov 4, 2019 at 2:39 AM Rasmus Villemoes
wrote:
>
> On 01/11/2019 23.31, Leo Li wrote:
> >
> >
> >> -Original Message-
> >> From: Christophe Leroy
> >> Sent: Friday, November 1, 2019 11:30 AM
> >> To: Rasmus Villemoes ; Qiang Zhao
> >> ; Leo Li
> >> Cc: linuxppc-dev@lists.ozlabs.o
On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote:
> On 11/4/19 12:33 PM, Jason Gunthorpe wrote:
> ...
> >> diff --git a/drivers/infiniband/core/umem.c
> >> b/drivers/infiniband/core/umem.c
> >> index 24244a2f68cc..c5a78d3e674b 100644
> >> +++ b/drivers/infiniband/core/umem.c
> >> @@ -2
On 11/4/19 12:37 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 03:31:53PM -0500, Jerome Glisse wrote:
>>> Note for Jason: the (a) or (b) items are talking about the vfio case, which
>>> is
>>> one of the two call sites that now use pin_longterm_pages_remote(), and the
>>> other one is infin
On Mon, Nov 04, 2019 at 12:57:59PM -0800, John Hubbard wrote:
> On 11/4/19 12:37 PM, Jason Gunthorpe wrote:
> > On Mon, Nov 04, 2019 at 03:31:53PM -0500, Jerome Glisse wrote:
> >>> Note for Jason: the (a) or (b) items are talking about the vfio case,
> >>> which is
> >>> one of the two call sites
This patch series enables IOMMU support for pseries Secure VMs.
Tested using QEMU command line option:
"-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4,
iommu_platform=on,disable-modern=off,disable-legacy=on"
and
"-device virtio-blk-pci,scsi=off,bus=pci.0,
addr=0x5,drive
The hypervisor needs to access the contents of the page holding the TCE
entries while setting up the TCE entries in the IOMMU's TCE table. For
SecureVMs, since this page is encrypted, the hypervisor cannot access
valid entries. Share the page with the hypervisor. This ensures that the
hypervisor se
This enables IOMMU support for pseries Secure VMs.
Signed-off-by: Ram Pai
---
arch/powerpc/platforms/pseries/iommu.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 07f0847..18971
On 11/4/19 1:15 PM, Jason Gunthorpe wrote:
...
>> Right, and I thought about this when converting, and realized that the above
>> code is working around the current gup.c limitations, which are "cannot
>> support
>> gup remote with FOLL_LONGTERM".
>
> But AFAICT it doesn't have a problem, the pr
On 11/4/19 12:57 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote:
>> On 11/4/19 12:33 PM, Jason Gunthorpe wrote:
>> ...
diff --git a/drivers/infiniband/core/umem.c
b/drivers/infiniband/core/umem.c
index 24244a2f68cc..c5a78d3e674b 100644
On 11/4/19 10:52 AM, Jerome Glisse wrote:
> On Sun, Nov 03, 2019 at 01:18:07PM -0800, 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
On Mon, Nov 04, 2019 at 02:49:18PM -0800, John Hubbard wrote:
> On 11/4/19 10:52 AM, Jerome Glisse wrote:
> > On Sun, Nov 03, 2019 at 01:18:07PM -0800, John Hubbard wrote:
> >> Add tracking of pages that were pinned via FOLL_PIN.
> >>
> >> As mentioned in the FOLL_PIN documentation, callers who eff
Hi Dan, there is a question for you further down:
On 11/4/19 3:49 PM, Jerome Glisse wrote:
> On Mon, Nov 04, 2019 at 02:49:18PM -0800, John Hubbard wrote:
...
>>> Maybe add a small comment about wrap around :)
>>
>>
>> I don't *think* the count can wrap around, due to the checks in
>> user_page_
On systems where TM (Transactional Memory) is disabled the
tm-signal-sigreturn-nt test causes a SIGILL:
test: tm_signal_sigreturn_nt
tags: git_version:7c202575ef63
!! child died by signal 4
failure: tm_signal_sigreturn_nt
We should skip the test if TM is not available.
Fixes: 34642d70ac7
This patch cause oops on android mainline kernel about gadget audio_source.
Androidx86 run on android mainline kernel.
[ 385.104963] android_work: sent uevent USB_STATE=CONNECTED
[ 385.109006] android_work: sent uevent USB_STATE=DISCONNECTED
[ 385.182024] android_work: sent uevent USB_STATE=CONNEC
This patch cause oops on android mainline kernel about gadget audio_source.
Androidx86 run on android mainline kernel.
[ 385.104963] android_work: sent uevent USB_STATE=CONNECTED
[ 385.109006] android_work: sent uevent USB_STATE=DISCONNECTED
[ 385.182024] android_work: sent uevent USB_STATE=C
This driver
https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/usb/gadget/function/f_audio_source.c
2019-11-04 16:02 GMT+08:00, Takashi Iwai :
> Exactly which driver is hit? The code path is via hw_support_mmap()
> and it's currently:
>
> static bool hw_support
On 10/24/19 8:09 AM, David Hildenbrand wrote:
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 4f2e78a5e4db..af69f057913a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page, unsigned
> int orde
On Fri, Nov 1, 2019 at 3:12 AM Masahiro Yamada
wrote:
>
> Copying source files during the build time may not end up with
> as clean code as you expect.
>
> lib/fdt*.c simply wrap scripts/dtc/libfdt/fdt*.c, and it works
> nicely. Let's follow that approach for the arm decompressor, too.
>
> Add fou
Hi Rob,
(+CC: David Daney)
On Mon, Nov 4, 2019 at 11:00 PM Rob Herring wrote:
>
> On Fri, Nov 1, 2019 at 1:19 AM Masahiro Yamada
> wrote:
> >
> > These are kernel source code even though they are just two-line wrappers.
> >
> > Files without explicit license information fall back to GPL-2.0-only
On Tue, Nov 5, 2019 at 10:04 AM Rob Herring wrote:
>
> On Fri, Nov 1, 2019 at 3:12 AM Masahiro Yamada
> wrote:
> >
> > Copying source files during the build time may not end up with
> > as clean code as you expect.
> >
> > lib/fdt*.c simply wrap scripts/dtc/libfdt/fdt*.c, and it works
> > nicely.
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
>
> Our onlining/offlining code is unnecessarily complicated. Only memory
> blocks added during boot can have holes (a range that is not
> IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
> add_memory_resource()). All boo
On Thu, Oct 24, 2019 at 5:10 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was ini
On Mon, Nov 04, 2019 at 02:03:43PM -0800, John Hubbard wrote:
> On 11/4/19 12:57 PM, Jason Gunthorpe wrote:
> > On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote:
> >> On 11/4/19 12:33 PM, Jason Gunthorpe wrote:
> >> ...
> diff --git a/drivers/infiniband/core/umem.c
> b/driver
On Thu, Oct 24, 2019 at 5:11 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was ini
On 22/10/19 6:52 pm, christophe lombard wrote:
Fix up the pci config size of the OpenCAPI PCIe devices in the pseries
environment.
Most of OpenCAPI PCIe devices have 4096 bytes of configuration space.
It's not "most of", it's "all" - the OpenCAPI Discovery and
Configuration Spec requires the u
Le 04/11/2019 à 20:43, Segher Boessenkool a écrit :
On Mon, Nov 04, 2019 at 01:32:53PM +1100, Alastair D'Silva wrote:
When calling flush_icache_range with a size >4GB, we were masking
off the upper 32 bits, so we would incorrectly flush a range smaller
than intended.
This patch replaces the
On 01/11/2019 23:31, Rasmus Villemoes wrote :
> -Original Message-
> From: Rasmus Villemoes
> Sent: 2019年11月4日 16:38
> To: Leo Li ; Christophe Leroy ;
> Qiang Zhao
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; Scott Wood ;
> n
Hi All,
We still have DMA problems with some PCI devices. Since the PowerPC
updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if
we want to work with our PCI devices. The FSL P5020 and P5040 have these
problems currently.
Error message:
[ 25.654852] bttv 1000:04:05.0: o
65 matches
Mail list logo
