On Thu, Feb 14, 2019 at 11:38:22AM +0300, Dan Carpenter wrote:
> The CODA_FREE() macro just calls kvfree(). We can call that directly
> instead.
Added these to my (getting long) list of things that I really should get
upstreamed sometime soon now.
Jan
From: Huang Zijiang
Date: Thu, 14 Feb 2019 14:41:45 +0800
> The of_find_device_by_node() takes a reference to the underlying device
> structure, we should release that reference.
>
> Signed-off-by: Huang Zijiang
Applied, thank you.
On Wed, 2019-02-13 at 23:16 +0100, Anders Roxell wrote:
> Commit a893ea15d764 ("tpm: move tpm_chip definition to
> include/linux/tpm.h") introduced a build error when both ima and efi is
> enabled. What happens is that both headers (ima.h and efi.h) defines the
> same 'NONE' constant, and it broke
On Thu, Feb 14, 2019 at 4:18 PM Erwan Velu wrote:
>
>
> Le 14/02/2019 à 11:22, Rafael J. Wysocki a écrit :
> > On Thu, Feb 14, 2019 at 10:28 AM Erwan Velu wrote:
> >> Hey rafael,
> >>
> >> Does the V6 looks good to you ?
> > I've queued it up with some manual changes. No need to update.
>
> Ok,
On Thu, Feb 14, 2019 at 5:42 PM Erwan Velu wrote:
>
>
> Le 14/02/2019 à 11:22, Rafael J. Wysocki a écrit :
> > I've queued it up with some manual changes. No need to update.
>
> As this could help troubleshooting platforms and as some commits like
> the PSS one on Proliant servers were
On 2/14/19 8:54 AM, Tycho Andersen wrote:
> Hi,
>
> On Wed, Feb 13, 2019 at 05:01:30PM -0700, Khalid Aziz wrote:
>> From: Juerg Haefliger
>>
>> If the page is unmapped by XPFO, a data cache flush results in a fatal
>> page fault, so let's temporarily map the region, flush the cache, and then
>>
On Thu, 2019-02-14 at 06:40 +0500, Ivan Mironov wrote:
> Unfortunately, everything broke again after yet another suspend/resume.
> Currently I'm suspecting that my patch maybe only helps to survive the
> short suspend, but not the long one.
>
> After this bad suspend/resume, card reader
Hi Tony,
Please do not snip the on going discussion.
On 2/14/2019 9:11 PM, Tony Lindgren wrote:
> * Lokesh Vutla [190214 08:39]:
>> IMHO, device ids are something which can be used in DT. There are many other
>> things like the interrupt ranges etc.. which are discoverable from sysfw and
Am Donnerstag, den 14.02.2019, 18:26 +0100 schrieb Lucas Stach:
> Am Donnerstag, den 14.02.2019, 17:18 + schrieb Abel Vesa:
> > On 19-02-14 16:50:28, Lucas Stach wrote:
> > > Hi Abel
> > >
> > > Am Mittwoch, den 13.02.2019, 19:05 + schrieb Abel Vesa:
> > > > Add the opp table containing
On Thu, Feb 14, 2019 at 1:05 PM Sudeep Holla wrote:
>
> On Thu, Feb 14, 2019 at 11:16:09AM +, Sudeep Holla wrote:
> > On Wed, Feb 13, 2019 at 11:17:47PM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Feb 13, 2019 at 1:01 PM Sudeep Holla wrote:
>
> [...]
>
> > > > diff --git
Use multiple per-offset wait queues instead of one big wait queue per
region.
Signed-off-by: Hugo Lefeuvre
---
This patch is based on the simplify handle_vsoc_cond_wait patchset,
currently under review: https://lkml.org/lkml/2019/2/7/870
---
drivers/staging/android/TODO | 4 ---
On 2/14/2019 6:02 AM, Rob Herring wrote:
> On Wed, Feb 13, 2019 at 4:09 PM Ray Jui wrote:
>>
>>
>>
>> On 2/13/2019 1:18 PM, Rob Herring wrote:
>>> On Mon, Feb 04, 2019 at 03:15:52PM -0800, Ray Jui wrote:
From: Rayagonda Kokatanur
Update iProc I2C binding document to add new
On 14/02/2019 16:05, Christian Borntraeger wrote:
On 14.02.2019 15:54, Cornelia Huck wrote:
On Thu, 14 Feb 2019 14:51:01 +0100
Pierre Morel wrote:
Pierre,
this is independent from this series and should have been sent separately.
In the end (when we have the final solution) this will require
The 'active_only' attribute was accidentally never set to true for any
power domains meaning that all the code handling this attribute was
dead.
NOTE that the RPM power domain code (as opposed to the RPMh one) gets
this right.
Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain
On 2/14/2019 6:16 AM, Rob Herring wrote:
> On Wed, Feb 13, 2019 at 4:06 PM Ray Jui wrote:
>>
>> Hi Rob,
>>
>> On 2/13/2019 1:16 PM, Rob Herring wrote:
>>> On Mon, Feb 04, 2019 at 03:15:49PM -0800, Ray Jui wrote:
In prep for the introduction of polling mode into the driver, update the
On 14/02/2019 17:57, Cornelia Huck wrote:
On Thu, 14 Feb 2019 16:47:30 +0100 Pierre Morel
wrote:
On 14/02/2019 15:54, Cornelia Huck wrote:
On Thu, 14 Feb 2019 14:51:01 +0100 Pierre Morel
wrote:
+++ b/drivers/s390/crypto/vfio_ap_drv.c @@ -24,8 +24,9 @@
MODULE_LICENSE("GPL v2");
static
On Mon, Jan 28, 2019 at 1:44 PM Andrew F. Davis wrote:
>
> Previously the heap to allocate from was selected by a mask of allowed
> heap types. This may have been done as a primitive form of constraint
> solving, the first heap type that matched any set bit of the heap mask
> was allocated from,
On 14/02/19 01:59, Song Liu wrote:
>> I believe the direction is clear. It needs people to do the work.
>> > We're critically short of reviewers. I got precious little review of
>> > the original XArray work, which made Andrew nervous and delayed its
>> > integration. Now I'm getting little
Hi Baoquan,
Thank you for your review.
On Thu, Feb 14, 2019 at 06:12:36PM +0800, Baoquan He wrote:
> Hi Masa,
>
> On 02/11/19 at 08:31pm, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > The system sometimes crashes while memory hot-adding on KASLR
> > enabled system. The crash
Do you have needs for retouching your photos? Or do deep etching and
masking for your photos,
We are the image service provider who can do this for you.
Please send photos to start testing, then you cam judge the quality of our
service.
Thanks,
Cindy
Neudwied
Wdeinheim
> #endif
> +
> + /* If there is a pending TLB flush for this CPU due to XPFO
> + * flush, do it now.
> + */
Don't forget CodingStyle in all this, please.
> + if (cpumask_test_and_clear_cpu(cpu, _xpfo_flush)) {
> + count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
>
On Thu, Feb 14, 2019 at 09:56:24AM -0700, Khalid Aziz wrote:
> On 2/14/19 12:47 AM, Christoph Hellwig wrote:
> > On Wed, Feb 13, 2019 at 05:01:27PM -0700, Khalid Aziz wrote:
> >> +++ b/kernel/dma/swiotlb.c
> >> @@ -396,8 +396,9 @@ static void swiotlb_bounce(phys_addr_t orig_addr,
> >> phys_addr_t
* Lokesh Vutla [190214 17:32]:
> Hi Tony,
> Please do not snip the on going discussion.
>
> On 2/14/2019 9:11 PM, Tony Lindgren wrote:
> > * Lokesh Vutla [190214 08:39]:
> >> IMHO, device ids are something which can be used in DT. There are many
> >> other
> >> things like the interrupt
On 02/14, Kees Cook wrote:
>
> v2:
> - fix 1-byte-too-early-bail-out in truncation detection (Oleg)
> - add Samuel's "tested" tag
Looks correct...
but you know, I'll try to read this patch again tomorrow after sleep.
And I can't believe this code can't be simplified... but let me repeat
that
Hi Chanwoo,
On Thu, Feb 14, 2019 at 11:10:00PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> 2019년 2월 14일 (목) 오후 7:16, Matthias Kaehlcke 님이 작성:
> >
> > devfreq expects governors to call devfreq_monitor_suspend/resume()
> > in response to DEVFREQ_GOV_SUSPEND/RESUME events. Since the devfreq
> >
On Thu, Feb 14, 2019 at 06:34:59PM +0100, Hugo Lefeuvre wrote:
> Use multiple per-offset wait queues instead of one big wait queue per
> region.
>
> Signed-off-by: Hugo Lefeuvre
Have you tested this?
Noticed any performance speedups or slow downs?
thanks,
greg k-h
Hello Julia,
On Fri, Feb 8, 2019 at 1:57 AM Julia Lawall wrote:
>
> > - is this important enough to ping back to authors of affected modules?
> > - should this be added to the kernel as part of 'make coccicheck' ?
> > - does this result make people "feel better" about devm_init_work() ?
>
> If
On 19-02-14 18:32:40, Lucas Stach wrote:
> Am Donnerstag, den 14.02.2019, 18:26 +0100 schrieb Lucas Stach:
> > Am Donnerstag, den 14.02.2019, 17:18 + schrieb Abel Vesa:
> > > On 19-02-14 16:50:28, Lucas Stach wrote:
> > > > Hi Abel
> > > >
> > > > Am Mittwoch, den 13.02.2019, 19:05 +
On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger
wrote:
>
> Your shebang line exceeds BINPRM_BUF_SIZE.
> Before the said commit the kernel silently truncated the shebang line
> (and corrupted it),
> now it tells the user that the line is too long.
It doesn't matter if it "corrupted" things by
This patch series adds the following support to the iProc I2C driver:
- Increase maximum read transfer size to 255 bytes
- I2C slave mode
- Polling mode
- NIC I2C mode
This patch series is based on kernel v5.0-rc3 and available at:
https://github.com/Broadcom/arm64-linux.git
branch: i2c-slave-v5
Update the binding document to make the 'interrupts' property optional.
For certain revisions of the I2C controller (e.g., iProc NIC I2C), I2C
interrupt is unwired to the interrupt controller. In such case, this
'interrupts' property should be left unspecified, and driver will fall
back to polling
From: Rayagonda Kokatanur
Update iProc I2C binding document to add new compatible string
"brcm,iproc-nic-i2c". Optional property "brcm,ape-hsls-addr-mask" is
also added that allows configuration of the host view into the APE's
address for "brcm,iproc-nic-i2c"
Signed-off-by: Rayagonda Kokatanur
From: Rayagonda Kokatanur
Add NIC I2C support to the iProc I2C driver. Access to the NIC I2C base
registers requires going through the IDM wrapper to map into the NIC's
address space
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Ray Jui
---
drivers/i2c/busses/i2c-bcm-iproc.c | 79
From: Shreesha Rajashekar
Add slave mode support to the iProc I2C driver.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Michael Cheng
Signed-off-by: Shreesha Rajashekar
Signed-off-by: Ray Jui
---
drivers/i2c/busses/Kconfig | 1 +
drivers/i2c/busses/i2c-bcm-iproc.c | 314
On Wed, Feb 13, 2019 at 07:17:59AM -0500, Mimi Zohar wrote:
> Require signed kernel modules on systems with secure boot mode enabled.
>
> Requiring appended kernel module signatures may be configured, enabled
> on the boot command line, or with this patch enabled in secure boot
> mode.
But only
From: Rayagonda Kokatanur
Add polling support to the iProc I2C driver. Polling mode is
activated when the driver fails to obtain an interrupt ID from device
tree
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Ray Jui
---
drivers/i2c/busses/i2c-bcm-iproc.c | 298
From: Rayagonda Kokatanur
Add NIC i2c device node.
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Ray Jui
---
.../boot/dts/broadcom/stingray/stingray.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
From: Shreesha Rajashekar
Add support to allow I2C master read transfer up to 255 bytes.
Signed-off-by: Shreesha Rajashekar
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Ray Jui
---
drivers/i2c/busses/i2c-bcm-iproc.c | 98 +++---
1 file changed, 76 insertions(+),
From: Rayagonda Kokatanur
Use the following wrapper for read/write access of iProc i2c registers:
u32 iproc_i2c_rd_reg(struct bcm_iproc_i2c_dev *iproc_i2c,
u32 offset)
void iproc_i2c_wr_reg(struct bcm_iproc_i2c_dev *iproc_i2c, u32 offset,
u32 val)
This
On Wed, 13 Feb 2019, Atish Patra wrote:
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c
> @@ -66,6 +66,11 @@ void __init setup_smp(void)
> found_boot_cpu = 1;
> continue;
> }
> + if (cpuid >= NR_CPUS) {
On Thu, Feb 14, 2019 at 6:53 AM Waiman Long wrote:
>
> The ARM64 result is what I would have expected given that the change was
> to optimize for the uncontended case. The x86-64 result is kind of an
> anomaly to me, but I haven't bothered to dig into that.
I would say that the ARM result is
On Thu, Feb 14, 2019 at 8:43 AM Kees Cook wrote:
>
> This documents the parsing steps, and will fail to exec if the string was
> truncated with neither an end-of-line nor any trailing whitespace.
Is there any reason why we don't just revert 8099b047ecc4 ("exec:
load_script: don't blindly
On Wed, Feb 13, 2019 at 6:40 PM Martin K. Petersen
wrote:
>
>
> Evan,
>
> > If the backing device for a loop device is a block device, then mirror
> > the discard properties of the underlying block device into the loop
> > device. While in there, differentiate between REQ_OP_DISCARD and
> >
Hi Jassi,
Have you had a chance to review this fix? This is a critical fix for a
crash during driver shutdown.
Regards,
Ray
On 2/4/2019 11:22 AM, Scott Branden wrote:
> Fix looks good.
>
> On 2019-02-04 11:21 a.m., Ray Jui wrote:
>> From: Rayagonda Kokatanur
>>
>> RING_CONTROL reg was not
Hi Matthias,
I have compiled and run your changes on Odroid xu3 and v5.0-rc6.
There are kernel warnings because of mutex not held in function
devfreq_monitor_[start|stop]() in use cases:
1) a few times during registration of new devices devfreq_add_device()
2) poking the device from sysfs
ad
Hi David,
On 14/02/2019 14:49, David Long wrote:
> From: "David A. Long"
>
> V4.9 backport of spectre patches from Russell M. King's spectre branch.
> Patches have been kvm-unit-test'ed on an arndale, run through kernelci, and
> handed off to ARM for functional testing.
>
As for 4.14 and
On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
> > Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> > it generate slightly better code.
> >
> > Before this patch, down_read_trylock:
> >
> >
Hi Tony,
On 2/14/2019 11:16 PM, Tony Lindgren wrote:
> * Lokesh Vutla [190214 17:32]:
>> Hi Tony,
>> Please do not snip the on going discussion.
>>
>> On 2/14/2019 9:11 PM, Tony Lindgren wrote:
>>> * Lokesh Vutla [190214 08:39]:
IMHO, device ids are something which can be used in DT.
Greetings, block experts!
I'm trying to track down a KASAN warning I'm seeing in our downstream
4.19 kernel, and I could use a little help. The warning looks like
this:
[ 224.564894] BUG: KASAN: use-after-free in bt_for_each+0x1ac/0x28c
[ 224.571195] Read of size 8 at addr ffc17c621340 by
Hi,
Thanks for taking a look at this..
On 2/14/19 11:11 AM, Will Deacon wrote:
Hi Jeremy,
On Fri, Feb 08, 2019 at 06:47:17PM -0600, Jeremy Linton wrote:
ACPI 6.3 adds additional fields to the MADT GICC
structure to describe SPE PPI's. We pick these out
of the cached reference to the
The pull request you sent on Tue, 12 Feb 2019 21:07:45 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> trace-v5.0-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b6ea7bcf77831ee5741e903738a19c94715b15e9
Thank you!
--
On 2/14/19 9:26 AM, Alexandre Torgue wrote:
> GMAC IP is little-endian and used on several kind of CPU (big or little
> endian). Main callbacks functions of the stmmac drivers take care about
> it. It was not the case for dwmac4_get_timestamp function.
This is clearly a bugfix, so you should be
On Thu, Feb 14, 2019 at 9:59 AM Linus Torvalds
wrote:
>
> On Thu, Feb 14, 2019 at 8:43 AM Kees Cook wrote:
> >
> > This documents the parsing steps, and will fail to exec if the string was
> > truncated with neither an end-of-line nor any trailing whitespace.
>
> Is there any reason why we don't
The genpd_dev_pm_attach_by_name() simply takes the name and passes it
to of_property_match_string() where the argument is "const char *".
Adding a const here allows a later patch to add a const to
dev_pm_domain_attach_by_name() which allows drivers to pass in a name
that was declared "const" in a
As of the patch ("PM / Domains: Mark "name" const in
genpd_dev_pm_attach_by_name()") it's clear that the name in
dev_pm_domain_attach_by_name() can be const. Mark it as so. This
allows drivers to pass in a name that was declared "const" in a
driver.
Fixes: 27dceb81f445 ("PM / Domains: Introduce
On Thu, Feb 14, 2019 at 9:51 AM Linus Torvalds
wrote:
>
> The arm64 numbers scaled horribly even before, and that's because
> there is too much ping-pong, and it's probably because there is no
> "stickiness" to the cacheline to the core, and thus adding the extra
> loop can make the ping-pong
On 2/14/19 2:24 AM, Daniel Lezcano wrote:
On 13/02/2019 21:18, Atish Patra wrote:
Currently, clocksource registration happens for an invalid cpu for
non-smp kernels. This lead to kernel panic as cpu hotplug registration
will fail for those cpus. Moreover, riscv_hartid_to_cpuid can return
errors
Hi guys,
On 14/02/2019 15:56, Mark Rutland wrote:
> On Thu, Feb 14, 2019 at 07:26:24AM +, Zhang, Lei wrote:
>> On the Fujitsu-A64FX cores ver(1.0, 1.1), memory access may
>> cause an undefined fault (Data abort, DFSC=0b11).
>> This fault occurs under a specific hardware condition when a
Quoting Douglas Anderson (2019-02-14 09:36:33)
> The 'active_only' attribute was accidentally never set to true for any
> power domains meaning that all the code handling this attribute was
> dead.
>
> NOTE that the RPM power domain code (as opposed to the RPMh one) gets
> this right.
>
> Fixes:
Quoting Douglas Anderson (2019-02-14 10:12:49)
> As of the patch ("PM / Domains: Mark "name" const in
> genpd_dev_pm_attach_by_name()") it's clear that the name in
> dev_pm_domain_attach_by_name() can be const. Mark it as so. This
> allows drivers to pass in a name that was declared "const" in a
Quoting Douglas Anderson (2019-02-14 10:12:48)
> The genpd_dev_pm_attach_by_name() simply takes the name and passes it
> to of_property_match_string() where the argument is "const char *".
> Adding a const here allows a later patch to add a const to
> dev_pm_domain_attach_by_name() which allows
On Thu, Feb 14, 2019 at 5:46 AM Michal Hocko wrote:
>
> On Wed 06-02-19 13:12:59, Dan Williams wrote:
> [...]
> > * Userfaultfd for file-backed mappings and DAX
>
> I assume that other topics are meant to be FS track but this one is MM,
> right?
Yes, but I think it is the lowest priority of all
Add the TCAN4x5x SPI CAN driver. This device
uses the Bosch MCAN IP core along with a SPI
interface map. Leverage the MCAN common core
code to manage the MCAN IP.
This device has a special method to indicate a
write/read operation on the data payload.
Signed-off-by: Dan Murphy
---
v5 -
Hi Alex,
On 2/13/19 6:52 PM, Alex Williamson wrote:
> On Wed, 13 Feb 2019 12:06:10 +0100
> Eric Auger wrote:
>
>> pci_map_rom/pci_get_rom_size() performs memory access in the ROM.
>> In case the Memory Space accesses were disabled, readw() is likely to
>> crash the host with a synchronous
> Your subject is too long.
ok . i have changed it
> Please upgrade bash?
anyway now i have an upgraded one.
here is a clipping related to the error
-x---x
Thu Feb 14 23:49:13 IST 2019
Running test: kmod_test_0007 - run #4
kmod_test_0005: OK!
Hello
OK I did not give up on this patch series just got a little preoccupied with
some other kernel work. But here is the update per the comments.
It should be understood I broke these out for reviewability.
For instance the first patch does not compile on its own as including this
patch
DT binding documentation for TI TCAN4x5x driver.
Signed-off-by: Dan Murphy
---
v5 - No changes - https://lore.kernel.org/patchwork/patch/1033097/
.../devicetree/bindings/net/can/tcan4x5x.txt | 37 +++
1 file changed, 37 insertions(+)
create mode 100644
Migrate the m_can code to use the m_can_platform framework
code.
Signed-off-by: Dan Murphy
---
v5 - Updated copyright, change m_can_classdev to m_can_priv, removed extra
KCONFIG flag - https://lore.kernel.org/patchwork/patch/1033095/
drivers/net/can/m_can/Kconfig | 8 +-
Rename the common m_can_priv class structure to
m_can_classdev as this is more descriptive.
Signed-off-by: Dan Murphy
---
v5 - New patch per comment in v4 -
https://lore.kernel.org/patchwork/patch/1033095/
drivers/net/can/m_can/m_can.c | 95 +-
Create a m_can platform framework that peripherial
devices can register to and use common code and register sets.
The peripherial devices may provide read/write and configuration
support of the IP.
Signed-off-by: Dan Murphy
---
v5 - Created ops struct, renamed header to m_can.h, updated license
All device objects in the driver model contain fields that control the
handling of various power management activities. However, it's not
always useful. There are few instances where pseudo devices are added
to the model just to take advantage of many other features like
kobjects, udev events, and
On Thu, Feb 14, 2019 at 11:12:55PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> Looks good to me for making the function to remove the duplicate code.
> But, When I just tested the kernel build, following warnings occur
> about devfreq_governor_stop().
>
> In file included from
On 2/14/19 12:36 PM, Pierre Morel wrote:
On 14/02/2019 17:57, Cornelia Huck wrote:
On Thu, 14 Feb 2019 16:47:30 +0100 Pierre Morel
wrote:
On 14/02/2019 15:54, Cornelia Huck wrote:
On Thu, 14 Feb 2019 14:51:01 +0100 Pierre Morel
wrote:
+++ b/drivers/s390/crypto/vfio_ap_drv.c @@ -24,8
Hi Chanwoo,
On Thu, Feb 14, 2019 at 11:32:40PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> When I contributed the something to devfreq.c, if the newly added functions
> are internal/static, just added the function without 'devfreq_' prefix
> in order to distinguish them from the exported
hi Krzysztof,
Thanks fro your review comments.
On Thu, 14 Feb 2019 at 18:11, Krzysztof Kozlowski wrote:
>
> Hi Anand,
>
> Thanks for the patch. See comments below.
>
> On Wed, 13 Feb 2019 at 22:41, Anand Moon wrote:
> >
> > Add suspend-to-mem node to regulator core to be enabled or disabled
>
On 02/14/2019 01:02 PM, Will Deacon wrote:
> On Thu, Feb 14, 2019 at 11:33:33AM +0100, Peter Zijlstra wrote:
>> On Wed, Feb 13, 2019 at 03:32:12PM -0500, Waiman Long wrote:
>>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>>> it generate slightly better code.
>>>
>>>
On Sun, Feb 10, 2019 at 5:05 PM Jens Axboe wrote:
>
> On 2/10/19 8:44 AM, James Bottomley wrote:
> > On Sun, 2019-02-10 at 10:17 +0100, Mikael Pettersson wrote:
> >> On Sat, Feb 9, 2019 at 7:19 PM James Bottomley
> >> wrote:
> > [...]
> >>> I think the reason for this is that the block mq path
Hi Krzysztof,
Thanks for your review comments.
On Thu, 14 Feb 2019 at 18:29, Krzysztof Kozlowski wrote:
>
> On Wed, 13 Feb 2019 at 22:41, Anand Moon wrote:
> >
> > This patch adds configration for PMU (Power Management Unit) state
> > tuning for exynos4412 SoC in order to enter low-power mode
On Thu, 14 Feb 2019, Ming Lei wrote:
> The driver passes initial configuration for the interrupt allocation via
> a pointer to struct affinity_desc.
Btw, blindly copying a suggestion without proof reading is a bad idea. That
want's to be 'struct irq_affinity' obviously. Tired brain confused them
On Thu, Feb 14, 2019 at 06:04:16PM +0100, Christoph Hellwig wrote:
> This look fine to me, but I'm a little worried that as-is this will
> just create conflicts with my series..
I'll rebase on top of your patches once they are in. Or I can send both
series as a single set.
Preferences?
--
Hi Marc,
On Thu, Feb 14, 2019 at 10:43:06AM +, Marc Zyngier wrote:
> On Thu, 07 Feb 2019 20:58:12 +,
> Aaro Koskinen wrote:
> > On Thu, Feb 07, 2019 at 08:56:37AM +, Marc Zyngier wrote:
> > > On 06/02/2019 21:26, Aaro Koskinen wrote:
> > > > static void init_8259A(int auto_eoi)
> >
On Thu, 2019-02-14 at 09:58 -0800, Luis Chamberlain wrote:
> On Wed, Feb 13, 2019 at 07:17:59AM -0500, Mimi Zohar wrote:
> > Require signed kernel modules on systems with secure boot mode enabled.
> >
> > Requiring appended kernel module signatures may be configured, enabled
> > on the boot
https://bugzilla.kernel.org/show_bug.cgi?id=202511
>From reporter (Michael):
> Working on 4.17.19 (which is what I use) but any kernel 4.19* 4.20* I try has
> this issue. Built amdgpu as a module, when it tries to load it (or I try to
> modprobe it) I get
>
> amdgpu: Could not allocate 8192
On 2/13/19 2:35 AM, Philipp Zabel wrote:
On Tue, 2019-02-12 at 09:42 -0800, Steve Longerbeam wrote:
[...]
But what about this "SAT_MODE" field in the IC task parameter memory?
That just controls the saturation. The result after the matrix
multiplication is either saturated to [0..255] or to
Do you have needs for retouching your photos? Or do deep etching and
masking for your photos,
We are the image service provider who can do this for you.
Please send photos to start testing, then you cam judge the quality of our
service.
Thanks,
Cindy
Neudwied
Siegdurg
This patch add basic tracing of the devfreq workqueue and delayed work.
It aims to capture changes of the polling intervals and device state.
Reviewed-by: Chanwoo Choi
Signed-off-by: Lukasz Luba
---
drivers/devfreq/devfreq.c | 8
1 file changed, 8 insertions(+)
diff --git
The patch adds a new file for with trace events for devfreq
framework. They are used for performance analysis of the framework.
It also contains updates in MAINTAINERS file adding new entry for
devfreq maintainers.
Signed-off-by: Lukasz Luba
---
MAINTAINERS| 1 +
Hi all,
This patch set adds support for tracing in devfreq framework. It is related
to the discussion regarding devfreq workqueue mechanism and wake-ups.
These two tracing patches have been submitted in larger patch set, which
needs more discussion. For the further discussion and development
On Thu, 14 Feb 2019, David Howells wrote:
>
> Hi James,
>
> Here are some keyrings fixes.
For which kernel, -rc or 5.1?
--
James Morris
On 24.01.2019 20:37, Heiner Kallweit wrote:
> On 16.01.2019 07:24, Frederic Weisbecker wrote:
>> On Fri, Dec 28, 2018 at 12:11:12AM +0100, Heiner Kallweit wrote:
>>>
>>> # tracer: nop
>>> #
>>> # _-=> irqs-off
>>> # / _=>
On Thu, 14 Feb 2019 19:57:56 +0100
Lukasz Luba wrote:
> This patch add basic tracing of the devfreq workqueue and delayed work.
> It aims to capture changes of the polling intervals and device state.
>
> Reviewed-by: Chanwoo Choi
> Signed-off-by: Lukasz Luba
> ---
> drivers/devfreq/devfreq.c
Hi Lukasz,
On Thu, Feb 14, 2019 at 07:01:36PM +0100, Lukasz Luba wrote:
> Hi Matthias,
>
> I have compiled and run your changes on Odroid xu3 and v5.0-rc6.
> There are kernel warnings because of mutex not held in function
> devfreq_monitor_[start|stop]() in use cases:
> 1) a few times during
On Thu, Feb 14, 2019 at 10:13:54AM -0700, Khalid Aziz wrote:
> Patch 11 ("xpfo, mm: remove dependency on CONFIG_PAGE_EXTENSION") cleans
> all this up. If the original authors of these two patches, Juerg
> Haefliger and Julian Stecklina, are ok with it, I would like to combine
> the two patches in
On Thu, Feb 14, 2019 at 10:25:07AM -0800, Dan Williams wrote:
> On Thu, Feb 14, 2019 at 5:46 AM Michal Hocko wrote:
> >
> > On Wed 06-02-19 13:12:59, Dan Williams wrote:
> > [...]
> > > * Userfaultfd for file-backed mappings and DAX
> >
> > I assume that other topics are meant to be FS track but
On Wed, Feb 13, 2019 at 07:37:57PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.157 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Wed, Feb 13, 2019 at 07:37:55PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.100 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Wed, Feb 13, 2019 at 07:38:01PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.22 release.
> There are 44 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
horizontal blank is computed by adding all porch timing values,
or htotal total timing value without sync time.
Based on "DRM kernel-internal display mode structure" from
include/drm/drm_modes.h
hblk = htotal - (hsync value);
hblk = htotal - (hsync_end - hsync_start);
Current driver is
Current driver is calculating hfp maximum value by subtracting
htotal with hsync_end which is back porch value, but the hfp
refers to front porch.
Front porch value is calculating by subtracting hsync_start with
hdisplay as per drm_mode timings, and BSP code from BPI-M64-bsp
is eventually
Like other dsi setup timings, hblk would also require to add
packet overhead.
Add 10 bytes packet overhead for hblk, so the blank is set using
a blanking packet like (4 bytes + 4 bytes + payload + 2 bytes)
The value 10 bytes are refereed from Allwinner BSP like how other
dsi setup timings grabs
801 - 900 of 1632 matches
Mail list logo
