On Thu, Jan 24, 2019 at 10:17 AM Peng Hao wrote:
>
> QEMU community requires additional PCI devices to simulate PVPANIC
> devices so that some architectures can not occupy precious less than 4G
> of memory space.
> Previously, I added PCI driver directly to the original version of the driver,
>
On Thu, Jan 24, 2019 at 10:17 AM Peng Hao wrote:
>
> Make pvpanic acpi driver as separate file and modify code
> in order to adapt the framework.
This should be patch 2 in this series to avoid run-time bisectability issues.
>
> Signed-off-by: Peng Hao
> ---
> drivers/misc/pvpanic/Kconfig
On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
wrote:
>
> On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> wrote:
> >
> > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > > wrote:
> > >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > >>>
On Thu, Jan 24, 2019 at 10:17 AM Peng Hao wrote:
>
> Add pvpanic_add/remove_device API. Follow-up patches will use them to
> add/remove specific drivers into framework.
I'm not sure this is the best way to instantiate the drivers.
Code with platfrom_device_add*() is related to platform which
On Thu, Jan 24, 2019 at 10:17 AM Peng Hao wrote:
>
> Add pvpanic driver framework. Follow-up patches will split the original
> pvpanic acpi/of driver as the two separate files and modify code to
> adapt the framework.
>
This one has run-time bisectability issues.
> Signed-off-by: Peng Hao
>
From: Andre Przywara
A host running in VHE mode gets the EL2 physical timer as its time
source (accessed using the EL1 sysreg accessors, which get re-directed
to the EL2 sysregs by VHE).
The EL1 physical timer remains unused by the host kernel, allowing us to
pass that on directly to a KVM
> On 24 Jan 2019, at 14.36, Andy Shevchenko wrote:
>
> On Thu, Jan 24, 2019 at 3:19 PM Javier González wrote:
>>> On 24 Jan 2019, at 13.16, Andy Shevchenko
>>> wrote:
>>> On Mon, Jan 21, 2019 at 09:47:32AM +0100, Christoph Hellwig wrote:
On Thu, Jan 10, 2019 at 04:30:51PM +0200, Andy
Dne 23.1.2019 v 13:46 Leo Yan napsal(a):
> Hi all,
>
> On Wed, Jan 23, 2019 at 12:58:51PM +0100, Takashi Iwai wrote:
>> On Tue, 22 Jan 2019 21:25:35 +0100,
>> Mark Brown wrote:
>>>
>>> On Mon, Jan 21, 2019 at 03:15:43PM +0100, Jaroslav Kysela wrote:
Dne 21.1.2019 v 13:40 Mark Brown
In function blk_mq_make_request(), though data->cmd_flags will be
initialized with bio->opf, later bio->opf may be set as REQ_INTEGRITY
if enabled DIX. So need to use bio->opf instead of data->cmd_flags in
function blk_mq_rq_ctx_init(), or flags REQ_INTEGRITY will not be set
for rq->cmd_flags. It
The interrupt handler contains a workaround for RX hang applicable
to Zynq and AT91 only. Subsequent versions do not need this
workaround. This workaround unecessarily resets RX whenever RX used
bit read is observed, which can be often under heavy traffic. Hence
introduce an CAPS mask and a check
1. In current implementation, every VLPI will temporarily be mapped to
the first CPU in system (normally CPU0) and then moved to the real
scheduled CPU later.
2. So there is a time window and a VLPI may be sent to CPU0 instead of
the real scheduled vCPU, in a multi-CPU virtual machine.
3.
On Wed, Jan 23, 2019 at 05:55:33PM +0100, Kamil Konieczny wrote:
> Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/crypto/s5p-sss.c | 50
> 1 file changed, 46 insertions(+), 4
Hi Andrew,
On Thu, Jan 24, 2019 at 02:11:18PM +0100, Andrew Lunn wrote:
> > That's right, I'll fix it in v2. In such cases, the license text takes
> > precedence over the MODULE_LICENSE() definition ?
>
> I've also not seen any real discussion about this. But when i recently
> proposed patches
On Thu, Jan 24, 2019 at 3:19 PM Javier González wrote:
> > On 24 Jan 2019, at 13.16, Andy Shevchenko
> > wrote:
> > On Mon, Jan 21, 2019 at 09:47:32AM +0100, Christoph Hellwig wrote:
> >> On Thu, Jan 10, 2019 at 04:30:51PM +0200, Andy Shevchenko wrote:
> >>> There are new types and helpers that
On Wed, Jan 09, 2019 at 12:47:29PM +0100, Sebastian Andrzej Siewior wrote:
> The `initialized' member of the fpu struct is always set to one user
^
for
> tasks and
On 2019-01-24 02:19, Aaro Koskinen wrote:
> Hi,
>
> On Sat, Jan 19, 2019 at 04:53:48PM +0800, liaoweixiong wrote:
>> On 2019-01-18 08:12, Kees Cook wrote:
MTD (drivers/mtd/mtdoops.c).
>>>
>>> Would mtdoops get dropped in favor of pstore/blk, or do they not share
>>> features?
>>
>> We can
Em Thu, Jan 24, 2019 at 11:39:22AM +0100, Jiri Olsa escreveu:
> On Wed, Jan 23, 2019 at 04:52:23PM -0800, Tony Jones wrote:
> > Seeteena posted, earlier this week, some patches to add Python3 support
> > to scripts/python/*.py. Unfortunately there were some issues with these
> > patches (such as:
On Thu, Jan 24, 2019 at 10:31:32AM +0800, Lu Baolu wrote:
> Commit 765b6a98c1de3 ("iommu/vt-d: Enumerate the scalable
> mode capability") enables VT-d scalable mode if hardware
> advertises the capability. As we will bring up different
> features and use cases to upstream in different patch
>
Hi Lu Baolu,
On Thu, Jan 24, 2019 at 02:47:39PM +0800, Lu Baolu wrote:
> bool iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)?
Looks good. Having a function to check for enabled features is certainly
a good thing.
Regards,
Joerg
> On 22 Jan 2019, at 11.15, h...@owltronix.com wrote:
>
> From: Hans Holmberg
>
> pblk_line_meta_free might sleep (it can end up calling vfree, depending
> on how we allocate lba lists), and this can lead to a BUG()
> if we wake up on a different cpu and release the lock.
>
> As there is no
Set up link interrupt if connection is handled by phylink otherwise
link state change detection for in-band-status doesn't work.
Fixes: 4bb043262878 ("net: mvpp2: phylink support")
Signed-off-by: Thomas Bogendoerfer
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
1 file changed, 1
> On 24 Jan 2019, at 13.16, Andy Shevchenko
> wrote:
>
> On Mon, Jan 21, 2019 at 09:47:32AM +0100, Christoph Hellwig wrote:
>> On Thu, Jan 10, 2019 at 04:30:51PM +0200, Andy Shevchenko wrote:
>>> There are new types and helpers that are supposed to be used in new code.
>>>
>>> As a
On Thu, Jan 24, 2019 at 01:36:23PM +0100, Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
> >
> > From: Eric Biggers
> >
> > Convert alg_test_skcipher() to use the new test framework, adding a list
> > of testvec_configs to test by default. When the extra self-tests
Maya Nakamura writes:
> Remove a duplicate definition of VP set (hv_vp_set) and use the common
> definition (hv_vpset) that is used in other places.
>
> Signed-off-by: Maya Nakamura
> ---
> drivers/pci/controller/pci-hyperv.c | 25 -
> 1 file changed, 12 insertions(+),
Add support of cancellation request to the TEE kernel internal
client interface. Can be used by software TPM drivers, that leverage
TEE under the hood (for instance in TPM2.0 mobile profile), for requesting
cancellation of time-consuming operations (RSA key-pair generation etc.).
Signed-off-by:
> That's right, I'll fix it in v2. In such cases, the license text takes
> precedence over the MODULE_LICENSE() definition ?
Hi Antoine
IANAL
I've also not seen any real discussion about this. But when i recently
proposed patches to cleanup similar issues in drivers/net/phy, i gave
the license
Hi,
On Tue, 2018-11-27 at 09:21 +0100, Maxime Ripard wrote:
> Hi!
>
> On Fri, Nov 23, 2018 at 02:02:09PM +0100, Paul Kocialkowski wrote:
> > This introduces support for HEVC/H.265 to the Cedrus VPU driver, with
> > both uni-directional and bi-directional prediction modes supported.
> >
> >
From: Varad Gautam
d_delete only unhashes an entry if it is reached with
dentry->d_lockref.count != 1. Prior to commit 8ead9dd54716 ("devpts:
more pty driver interface cleanups"), d_delete was called on a dentry
from devpts_pty_kill with two references held, which would trigger the
unhashing,
That's my bad. Thank you for your comment and effort.
Regards,
Kyungtae Kim
On Wed, Jan 23, 2019 at 4:34 PM Willem de Bruijn
wrote:
>
> On Mon, Jan 21, 2019 at 2:25 PM Kyungtae Kim wrote:
> >
> > I'm reporting a bug in linux-5.0-rc2: "UBSAN: Undefined behaviour in
> > net/ipv4/ip_output.c"
>
The vcpu idle_mask state is used by but not specific
to the emulated floating interruptions. The state is
relevant to gisa related interruptions as well.
Signed-off-by: Michael Mueller
---
arch/s390/include/asm/kvm_host.h | 2 +-
arch/s390/kvm/interrupt.c| 11 +--
Interruption types that are not represented in GISA shall
use pending_irqs_no_gisa() to test pending interruptions.
Signed-off-by: Michael Mueller
Reviewed-by: Cornelia Huck
Reviewed-by: Pierre Morel
---
arch/s390/kvm/interrupt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
The change helps to reduce line length and
increases code readability.
Signed-off-by: Michael Mueller
Reviewed-by: Cornelia Huck
Reviewed-by: Pierre Morel
---
arch/s390/kvm/interrupt.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
Use this struct analog to the kvm interruption structs
for kvm emulated floating and local interruptions.
Further fields will be added with this series as
required.
Signed-off-by: Michael Mueller
---
arch/s390/include/asm/kvm_host.h | 6 -
arch/s390/kvm/interrupt.c| 52
The databook clearly states that the MSI IRQ (msi_ctrl_int) is a level
triggered interrupt.
The msi_ctrl_int will be high for as long as any MSI status bit is set,
thus the IRQ type should be set to IRQ_TYPE_LEVEL_HIGH, causing the
IRQ handler to keep getting called, as long as any MSI status bit
The Guest Information Block (GIB) links the GISA of all guests
that have adapter interrupts pending. These interrupts cannot be
delivered because all vcpus of these guests are currently in WAIT
state or have masked the respective Innterruption Sub Class (ISC).
If enabled, a GIB alert is issued on
This patch implements the Set Guest Information Block operation
to request association or disassociation of a Guest Information
Block (GIB) with the Adapter Interruption Facility. The operation
is required to receive GIB alert interrupts for guest adapters
in conjunction with AIV and GISA.
Adding the kvm reference to struct sie_page2 will allow to
determine the kvm a given gisa belongs to:
container_of(gisa, struct sie_page2, gisa)->kvm
This functionality will be required to process a gisa in
gib alert interruption context.
Signed-off-by: Michael Mueller
Reviewed-by: Pierre
The explicit else path specified in set_intercept_indicators_io
is not required as the function returns in case the first branch
is taken anyway.
Signed-off-by: Michael Mueller
---
arch/s390/kvm/interrupt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Add the Interruption Alert Mask (IAM) to the architecture specific
kvm struct. This mask in the GISA is used to define for which ISC
a GIB alert will be issued.
The functions kvm_s390_gisc_register() and kvm_s390_gisc_unregister()
are used to (un)register a GISC (guest ISC) with a virtual machine
By initializing the GIB, it will be used by the kvm host.
Signed-off-by: Michael Mueller
Reviewed-by: Pierre Morel
---
arch/s390/kvm/kvm-s390.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 0e6ba4d17207..dcf6d62b4e80 100644
The Guest Information Area (GIB) and its mechanics is part of
the AIV facility. It provides hardware support to process
Adapter Interruptions (AI) for pagable storage mode guests.
Whenever a guest cannot process an AI because none of its
vcpus is running in SIE context, a GIB alert interruption
Use a consistent bitmap declaration throughout the code.
Signed-off-by: Michael Mueller
---
arch/s390/include/asm/kvm_host.h | 2 +-
arch/s390/kvm/interrupt.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/include/asm/kvm_host.h
The patch implements a handler for GIB alert interruptions
on the host. Its task is to alert guests that interrupts are
pending for them.
A GIB alert interrupt statistic counter is added as well:
$ cat /proc/interrupts
CPU0 CPU1
...
GAL: 23 37 [I/O] GIB Alert
This will shorten the length of code lines. All GISA related
static inline functions are local to interrupt.c.
Signed-off-by: Michael Mueller
---
arch/s390/kvm/interrupt.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/s390/kvm/interrupt.c
On Wednesday, January 23, 2019 6:04 AM, Kees Cook wrote
>
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
This reverts commit cf20ae1535eb690a87c29b9cc7af51881384e967.
The vb2_find_timestamp helper was modified to allow finding buffers
regardless of their current state in the queue. This means that we
no longer have to take particular care of references to the current
capture buffer.
Signed-off-by:
The apcs node has #clock-cells = <0>, which means that those who
references it should specify 0 arguments.
The apcs reference in the cpu node incorrectly specifies an argument,
remove this bogus argument.
Fixes: 65afdf458360 ("arm64: dts: qcom: msm8916: Add CPU frequency scaling
support")
On Wed, Dec 19, 2018 at 06:11:59PM +0530, Kishon Vijay Abraham I wrote:
> Instead of creating a new irqchip with empty callback functions, use
> dummy_irq_chip. Since there is nothing to do in the irqchip callback
> functions, use handle_simple_irq instead of handle_level_irq.
>
> Signed-off-by:
Dominique Martinet wrote on Thu, Jan 24, 2019:
> I was thinking of something along the lines of:
> return vma_is_anonymous(vma) || (vma->vm_file &&
> (inode_owner_or_capable(file_inode(vma->vm_file))
>|| inode_permission(file_inode(vma->vm_file),
On 13:43-20190124, Faiz Abbas wrote:
> Hi,
>
> On 17/01/19 3:14 PM, Faiz Abbas wrote:
> > The following patches add eMMC support on TI's AM65x-evm.
> >
> > v3:
> > 1. Fixed patch titles to only include eMMC
> > 2. Added dma-coherent to the sdhci0 node
Hi,
On Thu, 2019-01-24 at 11:32 +0100, Greg KH wrote:
> On Thu, Jan 24, 2019 at 10:55:42AM +0100, Paul Kocialkowski wrote:
> > This reverts commit cf20ae1535eb690a87c29b9cc7af51881384e967.
> >
> > The vb2_find_timestamp helper was modified to allow finding buffers
> > regardless of their current
On Thu, Jan 24, 2019 at 11:21:53AM +, Patrick Bellasi wrote:
> When a task-specific uclamp value is changed for a task, instead, a
> dequeue/enqueue is not needed. As long as we are doing a lazy update,
> that sounds just like not necessary overhead.
When that overhead is shown to be a
On 24-Jan 12:30, Patrick Bellasi wrote:
> On 23-Jan 21:11, Peter Zijlstra wrote:
> > On Wed, Jan 23, 2019 at 02:40:11PM +, Patrick Bellasi wrote:
> > > On 23-Jan 11:49, Peter Zijlstra wrote:
> > > > On Tue, Jan 15, 2019 at 10:15:06AM +, Patrick Bellasi wrote:
[...]
> > I'm thikning that
On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Convert alg_test_skcipher() to use the new test framework, adding a list
> of testvec_configs to test by default. When the extra self-tests are
> enabled, randomly generated testvec_configs are tested as well.
>
> This
On Thu, 24 Jan 2019 at 13:31, Koenig, Christian
wrote:
>
> Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> > The DRM driver stack is designed to work with cache coherent devices
> > only, but permits an optimization to be enabled in some cases, where
> > for some buffers, both the CPU and the GPU
On 23-Jan 21:11, Peter Zijlstra wrote:
> On Wed, Jan 23, 2019 at 02:40:11PM +, Patrick Bellasi wrote:
> > On 23-Jan 11:49, Peter Zijlstra wrote:
> > > On Tue, Jan 15, 2019 at 10:15:06AM +, Patrick Bellasi wrote:
> > > > @@ -858,16 +859,23 @@ static inline void
> > > >
On Wed, Jan 23, 2019 at 01:02:12PM -0800, Maya Nakamura wrote:
> @@ -908,12 +906,12 @@ static void hv_irq_unmask(struct irq_data *data)
> struct retarget_msi_interrupt *params;
> struct hv_pcibus_device *hbus;
> struct cpumask *dest;
> + cpumask_var_t tmp;
> struct
Hi Alex,
Thanks for the comments!
On 1/24/19 10:44 AM, Alexandre Courbot wrote:
> On Fri, Jan 18, 2019 at 1:21 AM Stanimir Varbanov
> wrote:
>>
>> This refactored code for start/stop streaming vb2 operations and
>
> s/refactored/refactors?
Ack.
>
>> adds a state machine handling similar to
Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> The DRM driver stack is designed to work with cache coherent devices
> only, but permits an optimization to be enabled in some cases, where
> for some buffers, both the CPU and the GPU use uncached mappings,
> removing the need for DMA snooping and
On Thu, Jan 24, 2019 at 11:24:39AM +0530, Sumit Garg wrote:
> On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> might not be accessible to normal world (linux in this case) and rather
> accessible to secure world (OP-TEE in this case) only. So this driver
> aims to provides a
On 2019/1/24 6:41, Russell King - ARM Linux admin wrote:
> On Sat, Jan 05, 2019 at 11:28:19AM +0800, Yunsheng Lin wrote:
>> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
>>> I'll try to do further diagnosis over Christmas in case I've missed
>>> something, but I suspect it may be one of
On Wed 2019-01-23 11:22:01, Yangtao Li wrote:
> This brings the kernel doc in line with the function signature.
>
> Signed-off-by: Yangtao Li
Acked-by: Pavel Machek
> @@ -783,7 +783,7 @@ void pm_wakeup_ws_event(struct wakeup_source *ws,
> unsigned int msec, bool hard)
>
On Sat, Jan 12, 2019 at 01:55:57PM -0800, Andrey Smirnov wrote:
> Everyone:
>
> This series contains changes I made in order to enable support of PCIE
> IP block on i.MX8MQ SoCs.
>
> Changes since [v4]:
>
> - Collected Reviewed-by from Lucas
>
> - Replaced ((ARM || ARM64) && COMPILE_TEST)
Sent from my iPad
> On Jan 24, 2019, at 6:27 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Thu, 2019-01-10 at 21:32 +0800, ayaka wrote:
>> I forget a important thing, for the rkvdec and rk hevc decoder, it would
>> requests cabac table, scaling list, picture parameter set and reference
From: Alexey Brodkin
1. Remove "0x" prefix from unit-address of node names
--->8
sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
--->8
2. Make all hex addresses lowercase:
Sent from my iPad
> On Jan 24, 2019, at 6:36 PM, Paul Kocialkowski
> wrote:
>
> Hi,
>
>> On Tue, 2019-01-08 at 18:00 +0800, Ayaka wrote:
>>
>> Sent from my iPad
>>
>>> On Jan 8, 2019, at 4:38 PM, Paul Kocialkowski
>>> wrote:
>>>
>>> Hi,
>>>
On Tue, 2019-01-08 at 09:16 +0800,
On 2019-01-24 02:26, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Jan 23, 2019 at 08:05:11PM +0800, liaoweixiong wrote:
>> Why should we need pstore_block?
>> 1. Most embedded intelligent equipment have no persistent ram, which
>> increases costs. We perfer to cheaper solutions, like block devices.
>>
It is too much to add extra header search path for all files in
drivers/acpi/dptf/.
Fix up one C file, and remove the header search path.
Signed-off-by: Masahiro Yamada
---
My main motivation is to get rid of crappy header search path manipulation
from Kbuild core.
Before that, I want to
Hi,
On 09-01-19 11:52, Andy Shevchenko wrote:
New quirk enforces search for GPIO based on its type,
i.e. iterate over GpioIo resources only.
Signed-off-by: Andy Shevchenko
Acked-by: Mika Westerberg
---
- it was sent few weeks ago to Hans for testing, but better to re-test
I've just
On Mon, Jan 21, 2019 at 09:47:32AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 04:30:51PM +0200, Andy Shevchenko wrote:
> > There are new types and helpers that are supposed to be used in new code.
> >
> > As a preparation to get rid of legacy types and API functions do
> > the
On Wed, 23 Jan 2019 at 23:52, Eric Biggers wrote:
>
> From: Eric Biggers
>
> The arm64 NEON bit-sliced implementation of AES-CTR fails the improved
> skcipher tests because it sometimes produces the wrong ciphertext. The
> bug is that the final keystream block isn't returned from the assembly
>
On 11/01/19 1:08 PM, Faiz Abbas wrote:
> Some controllers might prematurely issue a data timeout during an erase
> command. Add a quirk to disable the interrupt when an erase command is
> issued.
I might have already asked this, but would it be possible to use the
existing
On 17/01/19 7:31 PM, Bartosz Golaszewski wrote:
> czw., 17 sty 2019 o 13:42 Sekhar Nori napisał(a):
>>
>> On 16/01/19 2:48 PM, Sekhar Nori wrote:
>>> On 14/01/19 10:09 PM, Bartosz Golaszewski wrote:
pon., 14 sty 2019 o 13:20 Sekhar Nori napisał(a):
>
> Hi Bartosz,
>
> On
Hi Jerome,
This patch seems to have plenty of Cc:s, but none of the right ones :)
For further iterations, I guess you could use git option --cc to make
sure everyone gets the whole series, and still keep the Cc:s in the
patches themselves relevant to subsystems.
This doesn't seem to be on top
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command
wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication
During hci down we observed IBS sleep commands are queued in the Tx
buffer and hci_uart_write_work is sending data to the chip which is
not required as the chip is powered off. This patch will disable IBS
and flush the Tx buffer before we turn off the chip.
Signed-off-by: Balakrishna Godavarthi
The below issues are found in our recent testing.
1. Observed device is not going into off state or not responding.
As wcn3990 require a power pulses to turn on the irrespctive of
igniting regulators, it was observed that power on or power off
pulses are not in sync with respective to
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.
The use of uncached GPU
On Thu, 24 Jan 2019 12:03:06 +1100
Andrew Donnellan wrote:
> On 24/1/19 8:52 am, Olof Johansson wrote:
> > But, I think the largest question I have (for a broader audience) is:
> >
> > I predict that we will see a handful of these kind of devices over the
> > upcoming future -- definitely from
Hello.
The vmalloc test driver(https://lkml.org/lkml/2019/1/2/52) has been
added to the linux-next. Therefore i would like to fix some stability
issues i identified using it. I explained those issues in detail here:
https://lkml.org/lkml/2018/10/19/786
There are two patches, i think they are
One of the vmalloc stress test case triggers the kernel BUG():
[60.562151] [ cut here ]
[60.562154] kernel BUG at mm/vmalloc.c:512!
[60.562206] invalid opcode: [#1] PREEMPT SMP PTI
[60.562247] CPU: 0 PID: 430 Comm: vmalloc_test/0 Not tainted 4.20.0+ #161
[60.562293]
commit 763b218ddfaf ("mm: add preempt points into
__purge_vmap_area_lazy()")
introduced some preempt points, one of those is making an
allocation more prioritized over lazy free of vmap areas.
Prioritizing an allocation over freeing does not work well
all the time, i.e. it should be rather a
The device was moved from misc device to character devices
to support multiple mei devices.
Cc: #v4.9+
Signed-off-by: Tomas Winkler
---
samples/mei/mei-amt-version.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/mei/mei-amt-version.c
Add icelake mei device id.
Cc:
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me-regs.h | 2 ++
drivers/misc/mei/pci-me.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
index 23739a60517f..bb1ee9834a02 100644
---
Hi Asutosh,
Thanks for the patch!
On 1/24/19 09:01, Asutosh Das wrote:
> Adapt to the new ICB framework for bus bandwidth voting.
It's actually called interconnect API or interconnect framework.
> This requires the source/destination port ids.
> Also this requires a tuple of values.
>
> The
On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
wrote:
>
> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> >>> [SNIP]
> >>> This is *exactly* my point the whole time.
> >>>
> >>> The
Hi heiko and thomas,
the SPDX license identifier is updated by the following patch, please
help to review, thanks.
https://patchwork.kernel.org/patch/10776935/
在 2019/1/18 下午8:34, Heiko Stuebner 写道:
Hi Thomas,
Am Freitag, 18. Januar 2019, 01:40:03 CET schrieb Thomas Gleixner:
On Thu, 30
On 11/01/19 1:08 PM, Faiz Abbas wrote:
> From: Chunyan Zhang
>
> Some standard SD host controllers can support both external dma
> controllers as well as ADMA/SDMA in which the SD host controller
> acts as DMA master. TI's omap controller is the case as an example.
>
> Currently the generic
On 01/24/2019 05:23 AM, masonccy...@mxic.com.tw wrote:
>> [...]
>>
>> > +module_platform_driver(rpc_spi_driver);
>>
>> RPC is not a SPI controller, it's a SPI and HF controller.
>>
>> Also, how difficult will it be to add the HF support ?
>
> One of my customers needs RPC SPI driver for our
Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
>>> [SNIP]
>>> This is *exactly* my point the whole time.
>>>
>>> The current code has
>>>
>>> static inline bool drm_arch_can_wc_memory(void)
On Thu, 24 Jan 2019, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 0f7555121609 ("drm/i915/gvt: release shadow batch buffer and wa_ctx before
> destroy one workload")
>
> Fixes tag
>
> Fixes: 0cce2823ed37 ("drm/i915/gvt/kvmgt:Refine error handling for
> prepare_execlist_workload")
>
>
On Thu, 24 Jan 2019 at 15:45, Daniel Thompson
wrote:
>
> On Thu, Jan 24, 2019 at 11:24:38AM +0530, Sumit Garg wrote:
> > OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/
> > services for TEE bus. So implement device enumeration using invoke
> > function: PTA_CMD_GET_DEVICES
On 01/24/2019 05:06 AM, masonccy...@mxic.com.tw wrote:
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +//
>> > +// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
>> > +// Copyright (C) 2018 Macronix International Co., Ltd.
>> > +//
>> > +// R-Car Gen3 RPC-IF SPI/QSPI/Octa driver
>>
>>Do we
On 01/24/2019 12:07 PM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> __bpf_redirect() and act_mirred checks this boolean
> to determine whether to prefix an ethernet header.
>
> Signed-off-by: Maciej Żenczykowski
I presume David would pick this up for net tree, so:
Acked-by:
On 01/24/2019 05:06 AM, masonccy...@mxic.com.tw wrote:
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +//
>> > +// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
>> > +// Copyright (C) 2018 Macronix International Co., Ltd.
>> > +//
>> > +// R-Car Gen3 RPC-IF SPI/QSPI/Octa driver
>>
>>Do we
On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > [SNIP]
> > This is *exactly* my point the whole time.
> >
> > The current code has
> >
> > static inline bool drm_arch_can_wc_memory(void)
> > {
> > #if defined(CONFIG_PPC) &&
Hi Greg at al,
Recently I have been looking at the device links code because of the
recent discussion on possibly using them in the DRM subsystem (see for
example https://marc.info/?l=linux-pm=154832771905309=2) and I have
found a few issues in that code which should be addressed by this patch
From: Rafael J. Wysocki
It is incorrect to call pm_runtime_get_sync() under
device_links_write_lock(), because it may end up trying to take
device_links_read_lock() while resuming the target device and that
will deadlock in the non-SRCU case, so avoid that by resuming the
supplier device in
From: Rafael J. Wysocki
Currently, it is not valid to add a device link from a consumer
driver ->probe callback to a supplier that is still probing too, but
generally this is a valid use case. For example, if the consumer has
just acquired a resource that can only be available if the supplier
1201 - 1300 of 1508 matches
Mail list logo
