Hi,
On 13/08/2020 15:41:34+1000, Victor Ding wrote:
> cmos_read_alarm() may leave certain fields of a struct rtc_time
> untouched; therefore, these fields contain garbage if not properly
> initialized, leading to inconsistent values when converting into
> time64_t.
> This patch to set all fields o
On Thu, Aug 13, 2020 at 05:11:20PM +1000, Daniel Axtens wrote:
> When returning results to userspace, do_sys_poll repeatedly calls
> put_user() - once per fd that it's watching.
>
> This means that on architectures that support some form of
> kernel-to-userspace access protection, we end up enabli
On Thu 2020-08-13 02:30:02, John Ogness wrote:
> On 2020-08-12, Petr Mladek wrote:
> > So, I have one crazy idea to add one more state bit so that we
> > could have:
> >
> > + committed: set when the data are written into the data ring.
> > + final: set when the data block could not longer get
Hi,
On 8/12/2020 3:01 AM, Stephen Boyd wrote:
Quoting Maulik Shah (2020-08-10 04:21:00)
Clear previous kernel's configuration during init by resetting
interrupts in enable bank to zero.
Can you please add some more information here about why we're not
clearing all the pdc irqs and only the one
On Thu, Aug 13, 2020 at 10:44:38AM +0800, Jacob Wen wrote:
> wake_up_bit() uses waitqueue_active() that needs the explicit smp_mb().
Sounds like the barrier should go into wake_up_bit then..
>
> Signed-off-by: Jacob Wen
> ---
> fs/block_dev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -
On Wed, Aug 12, 2020 at 02:06:52PM +0200, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline
Hi All,
On 05.08.2020 16:26, Marek Szyprowski wrote:
> On 16.07.2020 16:28, Lee Jones wrote:
>> When creating a platform device from an MFD cell description, we
>> allocate some memory and make a copy which is then stored inside the
>> platform_device's structure. However, care is not currently t
On 8/12/20 1:01 PM, Christian Eggers wrote:
Hi Lars
On Monday, 3 August 2020, 08:52:54 CEST, Lars-Peter Clausen wrote:
On 8/3/20 8:44 AM, Christian Eggers wrote:
...
is my patch sufficient, or would you prefer a different solution?
The code in normal upstream is correct, there is no need to p
On 8/13/20 10:05 AM, Jürgen Groß wrote:
> On 13.08.20 08:32, Oleksandr Andrushchenko wrote:
>> Juergen, Boris,
>>
>> can we please merge these via Xen Linux tree as I have collected enough
>> Ack/R-b?
>>
>> The series has DRM patches, but those anyway are Xen related, so I think
>>
>> this should
A new bus type "dfl" is introduced for private features which are not
initialized by DFL feature drivers (dfl-fme & dfl-afu drivers). So these
private features could be handled by separate driver modules.
DFL feature drivers (dfl-fme, dfl-port) will create DFL devices on
enumeration. DFL drivers c
This patch makes preparation for modularization of DFL sub feature
drivers.
DFL based FPGA devices may contain some IP blocks which are already
supported by kernel, most of them are supported by platform device
drivers. We could create platform devices for these IP blocks and get them
supported by
This patch adds support for the Nios handshake private feature on Intel
PAC (Programmable Acceleration Card) N3000.
The Nios is the embedded processor on the FPGA card. This private feature
provides a handshake interface to FPGA Nois firmware, which receives
retimer configuration command from host
This patchset makes it possible to develop independent driver modules
for DFL private features. It also helps to leverage existing kernel
drivers to enable some IP blocks in DFL.
Patch #1: Release the dfl mmio regions after enumeration, so that private
feature drivers could request mmio
Hi,
On 8/10/2020 5:39 PM, Felipe Balbi wrote:
Maulik Shah writes:
Clear previous kernel's configuration during init by resetting
interrupts in enable bank to zero.
Suggested-by: Stephen Boyd
Signed-off-by: Maulik Shah
---
drivers/irqchip/qcom-pdc.c | 12 +++-
1 file changed, 11
On 2020/8/13 15:08, Jin, Yao wrote:
On 8/13/2020 2:57 PM, Like Xu wrote:
Hi Yao,
On 2020/8/13 11:11, Jin, Yao wrote:
Hi Like,
On 8/12/2020 9:02 PM, Like Xu wrote:
On 2020/8/12 20:15, Arnaldo Carvalho de Melo wrote:
Em Wed, Aug 12, 2020 at 02:59:53PM +0800, Jin Yao escreveu:
Currently if
Quoting Maulik Shah (2020-08-13 00:17:18)
> Hi,
>
> On 8/12/2020 1:04 AM, Stephen Boyd wrote:
> > Quoting Maulik Shah (2020-08-10 04:20:55)
> >> msmgpio irqchip is not using return value of irq_set_wake call.
> >> Start using it.
> > Does this work when the irq parent isn't setup in a hierarchy?
>
Hi,
On 8/12/2020 1:40 AM, Doug Anderson wrote:
Hi,
On Mon, Aug 10, 2020 at 4:21 AM Maulik Shah wrote:
From: Douglas Anderson
This goes with the new irq_suspend_one() and irq_resume_one()
callbacks and allow us to easily pass things up to our parent.
Signed-off-by: Douglas Anderson
Signed-
On Wed, 12 Aug 2020, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 12:46 AM Lee Jones wrote:
> >
> > Enjoy!
>
> No.
>
> This causes new compiler warnings.
Hmm... that's frustrating.
Mea culpa. Apologies for this.
As you know this is unheard of from me.
> I pulled, did a basic test-compi
Hi,
Sure, i will take care these comments in v5.
Thanks,
Maulik
On 8/12/2020 1:39 AM, Doug Anderson wrote:
Hi,
On Mon, Aug 10, 2020 at 4:21 AM Maulik Shah wrote:
From: Douglas Anderson
The "struct irq_chip" has two callbacks in it: irq_suspend() and
irq_resume(). These two callbacks are
On Wed 12-08-20 13:38:35, Thomas Gleixner wrote:
> Thomas Gleixner writes:
> > Thomas Gleixner writes:
> >> Michal Hocko writes:
> >>> zone->lock should be held for a very limited amount of time.
> >>
> >> Emphasis on should. free_pcppages_bulk() can hold it for quite some time
> >> when a large
Hi,
On 8/12/2020 1:04 AM, Stephen Boyd wrote:
Quoting Maulik Shah (2020-08-10 04:20:55)
msmgpio irqchip is not using return value of irq_set_wake call.
Start using it.
Does this work when the irq parent isn't setup in a hierarchy?
yes it works fine even when parent isn't setup in hierarchy.
To avoid double calling of function cdns3_exit_roles when initialization
failed patch removes invoking this function from cdns3_core_init_role.
This function is invoked again from cdns3_probe when
cdns3_core_init_role returns error code.
Signed-off-by: Pawel Laszczak
---
drivers/usb/cdns3/core.c
When returning results to userspace, do_sys_poll repeatedly calls
put_user() - once per fd that it's watching.
This means that on architectures that support some form of
kernel-to-userspace access protection, we end up enabling and disabling
access once for each file descripter we're watching. Thi
Hi Rob,
Thanks for the review.
> -Original Message-
> From: Rob Herring
> Sent: Friday, July 17, 2020 3:57 AM
> To: TY_Chang[張子逸]
> Cc: linux-realtek-...@lists.infradead.org; afaer...@suse.de;
> linus.wall...@linaro.org; linux-g...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-ke
Am 2020-08-10 09:31, schrieb Michael Walle:
Am 2020-08-10 09:13, schrieb Lee Jones:
On Fri, 07 Aug 2020, Michael Walle wrote:
Hi Uwe, Hi Lee,
Am 2020-08-06 10:40, schrieb Uwe Kleine-König:
> On Mon, Aug 03, 2020 at 11:35:52AM +0200, Michael Walle wrote:
> > diff --git a/drivers/pwm/Kconfig b/
Hi Rob,
Thank you for the review.
> -Original Message-
> From: Rob Herring
> Sent: Friday, July 17, 2020 3:55 AM
> To: TY_Chang[張子逸]
> Cc: linux-realtek-...@lists.infradead.org; afaer...@suse.de;
> linus.wall...@linaro.org; linux-g...@vger.kernel.org;
> devicet...@vger.kernel.org; linux
Currently if we run 'perf record -e cycles:u', exclude_guest is 0.
But it doesn't make sense that we request for user-space counting
but we also get the guest report.
To keep perf semantics consistent and clear, this patch sets
exclude_guest for user-space counting.
Before:
perf record -e cyc
On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
> Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1
> (Beryllium)
>
> >// This removed_region is needed to boot the device
> > // TODO: Find out the user of this reserved memory
> > removed_regi
The CPUfreq HW present in some Mediatek chipsets offloads
the steps necessary for changing the frequency of CPUs.
The driver implements the cpufreq driver interface for
this hardware engine.
This patch depends on the MT6779 DTS patch submitted by Hanks Chen
https://lkml.org/lkml/2020/8/4/1094
From: "Hector.Yuan"
Add MT6779 cpufreq HW support.
Signed-off-by: Hector.Yuan
---
arch/arm64/configs/defconfig |1 +
drivers/cpufreq/Kconfig.arm | 11 ++
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/mediatek-cpufreq-hw.c | 255 ++
On 8/13/2020 2:57 PM, Like Xu wrote:
Hi Yao,
On 2020/8/13 11:11, Jin, Yao wrote:
Hi Like,
On 8/12/2020 9:02 PM, Like Xu wrote:
On 2020/8/12 20:15, Arnaldo Carvalho de Melo wrote:
Em Wed, Aug 12, 2020 at 02:59:53PM +0800, Jin Yao escreveu:
Currently if we run 'perf record -e cycles:u', ex
From: "Hector.Yuan"
Add devicetree bindings for MediaTek HW driver.
Signed-off-by: Hector.Yuan
---
.../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 61
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw
On Tue 11-08-20 10:29:24, David Hildenbrand wrote:
[...]
> I was wondering if we should rather set all pageblocks to
> MIGRATE_ISOLATE in online_pages() before doing the online_pages_range()
> call, and do undo_isolate_page_range() after onlining is done.
>
> move_pfn_range_to_zone()->memmap_init_
On 13.08.20 08:32, Oleksandr Andrushchenko wrote:
Juergen, Boris,
can we please merge these via Xen Linux tree as I have collected enough Ack/R-b?
The series has DRM patches, but those anyway are Xen related, so I think
this should be fine from DRI point of view.
Yes, fine with me.
Juergen
On 2020/08/13 15:45, Atish Patra wrote:
> On Wed, Aug 12, 2020 at 10:44 PM Damien Le Moal wrote:
>>
>> On 2020/08/13 12:40, Qiu Wenbo wrote:
>>> Exception vector is missing on nommu platform and that is an issue.
>>> This patch is tested in Sipeed Maix Bit Dev Board.
>>>
>>> Fixes: 79b1feba5455 ("
On 2020/08/11 4:29, Andrea Arcangeli wrote:
> However once the mutex is killable there's no concern anymore and the
> hangcheck timer is correct also not reporting any misbehavior anymore.
Do you mean something like below untested patch? I think that the difficult
part is that mutex for close() op
Hi all,
News: The merge window has opened, so please do not add any v5.10
related material to your linux-next included branches until after the
merge window closes again.
Changes since 20200812:
My fixes tree contains:
73c7adb54169 ("device_cgroup: Fix RCU list debugging warning")
Linus' tre
901 - 937 of 937 matches
Mail list logo
