On Thu, Oct 18, 2018 at 9:50 AM Ingo Molnar wrote:
>
>
> * Rafael J. Wysocki wrote:
>
> > > The only long term maintainable solution is to move all high level
> > > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > > which has been done to a fair degree already in the past
On (10/18/18 09:56), Michal Hocko wrote:
> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
> [...]
> > and let's hear from MM people what they can suggest.
> >
> > Michal, Andrew, Johannes, any thoughts?
>
> I have already stated my position. Let's not reinvent the wheel and use
> the standar
On 10/16/18 6:49 PM, Doug Ledford wrote:
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Gustavo A. R. Silva
>
> Thanks, applied to for-rc.
>
Thanks, Doug.
--
Gustavo
Hi Vincent,
On 10/16/2018 07:11 PM, Vincent Guittot wrote:
> Hi Lukasz,
>
> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>
>>
>>
>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
>>> Hello Lukasz,
>>>
>>> On 10/10/2018 11:35 AM, Lukasz Luba wrote:
Hi Thara,
I have run it on Ex
On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote:
>
> On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote:
> > Some new touchpads IC are connected through PS/2 and I2C. On some of these
> > new IC, the I2C part doesn't have all of the information available.
> > We need to be able
I just noticed this in review. The get_register_interruptible() should
return zero on success but it instead returns the value that it read.
I looked at all the places that called this directly and they check for
negatives and treat greater than or equal to zero as success. This
function is also
On Mon, Oct 15, 2018 at 05:15:47PM +0300, Jarkko Nikula wrote:
> On 10/11/2018 05:29 PM, Hans de Goede wrote:
> > Now that most of the special Bay- / Cherry-Trail bus lock handling has
> > been moved to the iosf_mbi code we can simplify the remaining code a bit.
> >
> > Signed-off-by: Hans de Goed
Cast *max_num_sg* to u64 in order to give the compiler complete
information about the proper arithmetic to use.
Notice that such variable is used in a context that expects an
expression of type u64 (64 bits, unsigned) and the following
expression is currently being evaluated using 32-bit
arithmeti
On 10/18/2018 10:36 AM, Andy Shevchenko wrote:
On Thu, Oct 18, 2018 at 10:33 AM Rafael J. Wysocki wrote:
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
kernel. The P-Unit has a semaphore for the PMIC bus which we can
On 10/17/2018 06:24 PM, Thara Gopinath wrote:
> On 10/16/2018 01:11 PM, Vincent Guittot wrote:
>> Hi Lukasz,
>>
>> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote:
>>>
>>>
>>>
>>> On 10/10/2018 07:30 PM, Thara Gopinath wrote:
Hello Lukasz,
On 10/10/2018 11:35 AM, Lukasz Luba wrote
Some SOCs in the i.MX6 family have a USB host controller that is
only capable of the HSIC interface and has no on-board PHY.
To be able to use these controllers, we need to add "usb-nop-xceiv"
dummy PHYs.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6qdl.dtsi | 14 ++
ar
Hi Balakrishna,
> This patch will prevent error messages splashing on console.
> [ 78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
> packet for unknown connection handle 3804
> [ 78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
>
Hi Balakrishna,
> This patch will prevent error messages splashing on console.
>
> [ 78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet
> for unknown connection handle 3804
> [ 78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet
> for unknown connectio
On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
[...]
> and let's hear from MM people what they can suggest.
>
> Michal, Andrew, Johannes, any thoughts?
I have already stated my position. Let's not reinvent the wheel and use
the standard printk throttling. If there are cases where oom reports
On Wed, Oct 17, 2018 at 06:22:48PM -0700, Andy Lutomirski wrote:
>
> > On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote:
> >
> > It is sometimes beneficial to prevent preemption for very few
> > instructions, or prevent preemption for some instructions that precede
> > a branch (this latter case wi
On 10/17/2018 9:41 PM, Doug Anderson wrote:
Hi,
On Tue, Oct 16, 2018 at 11:28 PM Vivek Gautam
wrote:
Hi Doug,
On 10/16/2018 10:29 PM, Doug Anderson wrote:
Hi,
On Mon, Oct 15, 2018 at 10:51 PM Vivek Gautam
wrote:
P.S.: While you are at it, can you please move 'ufs-qcom.txt'
to Document
* Rafael J. Wysocki wrote:
> > The only long term maintainable solution is to move all high level
> > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c,
> > which has been done to a fair degree already in the past ~2 years - but
> > it's unclear to me to what extent this is tr
From: Shun-Chih Yu
Document the devicetree bindings for MediaTek Command-Queue DMA controller
which could be found on MT6765 SoC or other similar Mediatek SoCs.
Signed-off-by: Shun-Chih Yu
Reviewed-by: Rob Herring
---
.../devicetree/bindings/dma/mtk-cqdma.txt | 31
* Jan Kara:
> On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
>> FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to
>> add new flags and did not want to change the UAPI _ALL_ constants.
>> This is how we plan to solve it:
>> https://github.com/amir73il/linux/commit/8c2b1aca
From: Shun-Chih Yu
MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated
to memory-to-memory transfer through queue based descriptor management.
There are only 3 physical channels inside CQDMA, while the driver is
extended to support 32 virtual channels for multiple dma users
Changes since v2:
- fix build warning for kernel with DMA address in 32-bit
Changes since v1:
- remove unused macros, typos
- leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list
Shun-Chih Yu (2):
dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller
binding
On Mon, Oct 15, 2018 at 5:09 PM Alexander Duyck
wrote:
>
> This patch is meant to try and consolidate all of the locking and unlocking
> of both the parent and device when attaching or removing a driver from a
> given device.
>
> To do that I first consolidated the lock pattern into two functions
On Thu, Oct 18, 2018 at 9:39 AM, Florian Weimer wrote:
> * Miklos Szeredi:
>
>> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
>>> * Andreas Dilger:
>>>
> So what's the point exactly?
Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
to mask o
On Thu 18-10-18 01:15:13, Amir Goldstein wrote:
> On Wed, Oct 17, 2018 at 10:12 PM Miklos Szeredi wrote:
>
> > >> - STATX_ALL definition is unclear, can this change, or is it fixed?
> > >> If it's the former, than that's a backward compatibility nightmare.
> > >> If it's the latter, then what's t
On 10/18/2018 09:28 AM, Phil Reid wrote:
[...]
>> + chip->rdwr_pin = devm_gpiod_get(&spi_dev->dev, "rdwr", GPIOD_IN);
>> + if (IS_ERR(chip->rdwr_pin)) {
>> + ret = PTR_ERR(chip->rdwr_pin);
>> + dev_err(&spi_dev->dev, "Failed to request rdwr GPIO: %d\n",
>> + ret);
>>
* Miklos Szeredi:
> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
>> * Andreas Dilger:
>>
So what's the point exactly?
>>>
>>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
>>> to mask off flags that it doesn't currently understand. It doesn't make
>>
On Sun, Sep 23, 2018 at 04:45:10PM +0200, Hans de Goede wrote:
> Now that most of the special Bay- / Cherry-Trail bus lock handling has
> been moved to the iosf_mbi code we can simplify the remaining code a bit.
>
> Signed-off-by: Hans de Goede
Acked-by: Wolfram Sang
signature.asc
Descriptio
On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote:
> * Andreas Dilger:
>
>>> So what's the point exactly?
>>
>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
>> to mask off flags that it doesn't currently understand. It doesn't make
>> much sense for application
On Thu, Oct 18, 2018 at 10:33 AM Rafael J. Wysocki wrote:
>
> On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
> >
> > On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
> > kernel. The P-Unit has a semaphore for the PMIC bus which we can take to
> > block it from accessing
On Wed, Oct 17, 2018 at 03:49:39PM -0400, Steven Rostedt wrote:
>
> Linus (aka Greg),
>
> This fixes two bugs:
>
> - Fix size mismatch of tracepoint array
>
> - Have preemptirq test module use same clock source of the selftest
Now pulled, thanks.
greg k-h
On Wed, Oct 17, 2018 at 1:24 PM Vitaly Kuznetsov wrote:
>
> It is possible to observe hung_task complaints when system goes to
> suspend-to-idle state:
>
> # echo freeze > /sys/power/state
>
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
>
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote:
>
> On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the
> kernel. The P-Unit has a semaphore for the PMIC bus which we can take to
> block it from accessing the shared bus while the kernel wants to access it.
>
> Currently we ha
On 17/10/2018 10:47 PM, Nishad Kamdar wrote:
Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
instead of the deprecated old non-descriptor interface.
Signed-off-by: Nishad Kamdar
---
Changes in v2:
- Correct the error messages as pin number being showed
has now been replaced
On Wed, Oct 17, 2018 at 10:22 PM, Andreas Dilger wrote:
> On Oct 17, 2018, at 1:04 PM, Miklos Szeredi wrote:
>> So what's the point exactly?
>
> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel
> to mask off flags that it doesn't currently understand.
And even there i
On Thu, Oct 18, 2018 at 10:11 AM Suganath Prabu Subramani
wrote:
>
>
>
> On Wed, Oct 17, 2018 at 2:02 PM Andy Shevchenko
> wrote:
>>
>> On Wed, Oct 17, 2018 at 8:59 AM Suganath Prabu
>> wrote:
>> >
>> > This is to fix Sync cache and start stop command
>> > failures with DID_NO_CONNECT during d
On Wed, Oct 17, 2018 at 5:49 PM, Dan Williams wrote:
> On Wed, Oct 17, 2018 at 5:29 PM Kees Cook wrote:
>>
>> When ramoops reserved a memory region in the kernel, it had an unhelpful
>> label of "persistent_memory". When reading /proc/iomem, it would be
>> repeated many times, did not hint that i
On Thu, Oct 18, 2018 at 07:43:02AM +0100, Jon Hunter wrote:
>
> On 16/10/2018 18:04, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.77 release.
> > There are 109 patches in this series, all will be posted as a response
> > to this one. If anyone has any is
On Wed, Oct 17, 2018 at 12:19:39PM -0700, Guenter Roeck wrote:
> On Tue, Oct 16, 2018 at 07:08:57PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.134 release.
> > There are 71 patches in this series, all will be posted as a response
> > to this one.
On Wed, Oct 17, 2018 at 12:30:28PM -0600, Shuah Khan wrote:
> On 10/16/2018 11:03 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.15 release.
> > There are 135 patches in this series, all will be posted as a response
> > to this one. If anyone has any is
On 10/18/18 12:21 AM, Dave Hansen wrote:
> On 10/17/2018 04:32 AM, Pavel Machek wrote:
>>> Well, that depends. Do you care about PROT_NONE attacks as well? If not
>>> then no-swap would help you. But even then no-swap is rather theoretical
>>> attack on a physical host unless you allow an arbitrary
On Wed, Oct 17, 2018 at 11:59 PM, Joel Fernandes (Google)
wrote:
> Add tests to verify sealing memfds with the F_SEAL_FS_WRITE works as
> expected.
I messed the commit message it should be "F_SEAL_FUTURE_WRITE", but
otherwise this
patch itself is good and I'll resend it with the corrected commit
On Thu, Oct 18, 2018 at 8:48 AM Ingo Molnar wrote:
>
>
> * Thara Gopinath wrote:
>
> > On 10/16/2018 03:33 AM, Ingo Molnar wrote:
> > >
> > > * Thara Gopinath wrote:
> > >
> > Regarding testing, basic build, boot and sanity testing have been
> > performed on hikey960 mainline kernel wi
Hi,
On 17.10.2018 19:30, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 11:57:49AM +0300, Alexey Budankov wrote:
>> Hi,
>>
>> On 10.10.2018 13:45, Peter Zijlstra wrote:
>>
>>> -static bool perf_rotate_context(struct perf_cpu_context *cpuctx)
>>> +/*
>>> + * XXX somewhat completely buggered; this
Hi all,
News: I will not be doing linux-next releases next week. Unfortunately
this will probably be the first week of the merge window. :-(
Changes since 20181017:
The kvm tree gained a conflict against Linus' tree.
The kvm-arm tree gained a conflict against the kvm tree.
The scsi-mkp tree g
On Wed 17-10-18 12:59:18, David Rientjes wrote:
> On Wed, 17 Oct 2018, Michal Hocko wrote:
>
> > Do you know of any other userspace except your usecase? Is there
> > anything fundamental that would prevent a proper API adoption for you?
> >
>
> Yes, it would require us to go back in time and bui
701 - 745 of 745 matches
Mail list logo
