On Mon, 03 Dec 2018 16:53:17 +0100,
Thierry Reding wrote:
>
> From: Thierry Reding
>
> Tegra186 and Tegra194 contain the same codecs as earlier chips and can
> be supported using the same patch function.
>
> Signed-off-by: Thierry Reding
Applied now, thanks.
Takashi
On Mon 03 Dec 07:34 PST 2018, Jeffrey Hugo wrote:
> The offsets for the defined BCR reset registers does not match the hardware
> documentation. Update the values to match the hardware documentation.
>
Sorry for not spotting this before.
> Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global
On Mon, 03 Dec 2018 16:53:17 +0100,
Thierry Reding wrote:
>
> From: Thierry Reding
>
> Tegra186 and Tegra194 contain the same codecs as earlier chips and can
> be supported using the same patch function.
>
> Signed-off-by: Thierry Reding
Applied now, thanks.
Takashi
On Mon 03 Dec 07:34 PST 2018, Jeffrey Hugo wrote:
> The offsets for the defined BCR reset registers does not match the hardware
> documentation. Update the values to match the hardware documentation.
>
Sorry for not spotting this before.
> Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global
On Mon, 03 Dec 2018 16:53:16 +0100,
Thierry Reding wrote:
>
> From: Thierry Reding
>
> Recent devices support more than the 4 codecs that the AZX core will
> probe by default. Probe up to 8 codecs to make sure all of them are
> enumerated.
>
> Suggested-by: Sameer Pujar
> Signed-off-by:
On Mon, 03 Dec 2018 16:53:16 +0100,
Thierry Reding wrote:
>
> From: Thierry Reding
>
> Recent devices support more than the 4 codecs that the AZX core will
> probe by default. Probe up to 8 codecs to make sure all of them are
> enumerated.
>
> Suggested-by: Sameer Pujar
> Signed-off-by:
Commit-ID: 182ddd16194cd082f25fa1b063dae3c7c5cce384
Gitweb: https://git.kernel.org/tip/182ddd16194cd082f25fa1b063dae3c7c5cce384
Author: Juergen Gross
AuthorDate: Mon, 3 Dec 2018 11:38:11 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Dec 2018 11:56:37 +0100
x86/boot: Clear RSDP
Commit-ID: 182ddd16194cd082f25fa1b063dae3c7c5cce384
Gitweb: https://git.kernel.org/tip/182ddd16194cd082f25fa1b063dae3c7c5cce384
Author: Juergen Gross
AuthorDate: Mon, 3 Dec 2018 11:38:11 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Dec 2018 11:56:37 +0100
x86/boot: Clear RSDP
On Tue, Nov 20, 2018 at 9:38 PM Manivannan Sadhasivam
wrote:
>
> Add initial devicetree support for OrangePi 2G IoT board from Xunlong.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/boot/dts/Makefile| 2 +
>
On Tue, Nov 20, 2018 at 9:38 PM Manivannan Sadhasivam
wrote:
>
> Add initial devicetree support for OrangePi 2G IoT board from Xunlong.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/boot/dts/Makefile| 2 +
>
From: Thierry Reding
Tegra186 and Tegra194 contain the same codecs as earlier chips and can
be supported using the same patch function.
Signed-off-by: Thierry Reding
---
sound/pci/hda/patch_hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c
From: Thierry Reding
Recent devices support more than the 4 codecs that the AZX core will
probe by default. Probe up to 8 codecs to make sure all of them are
enumerated.
Suggested-by: Sameer Pujar
Signed-off-by: Thierry Reding
---
sound/pci/hda/hda_tegra.c | 2 +-
1 file changed, 1
From: Thierry Reding
Tegra186 and Tegra194 contain the same codecs as earlier chips and can
be supported using the same patch function.
Signed-off-by: Thierry Reding
---
sound/pci/hda/patch_hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c
From: Thierry Reding
Recent devices support more than the 4 codecs that the AZX core will
probe by default. Probe up to 8 codecs to make sure all of them are
enumerated.
Suggested-by: Sameer Pujar
Signed-off-by: Thierry Reding
---
sound/pci/hda/hda_tegra.c | 2 +-
1 file changed, 1
On Sun, Dec 02, 2018 at 11:26:50PM -0600, Serge E. Hallyn wrote:
> On Sun, Dec 02, 2018 at 08:28:26PM -0700, Tycho Andersen wrote:
> > +struct seccomp_knotif {
> > + /* The struct pid of the task whose filter triggered the notification */
> > + struct task_struct *task;
> > +
> > + /* The
On Sun, Dec 02, 2018 at 11:26:50PM -0600, Serge E. Hallyn wrote:
> On Sun, Dec 02, 2018 at 08:28:26PM -0700, Tycho Andersen wrote:
> > +struct seccomp_knotif {
> > + /* The struct pid of the task whose filter triggered the notification */
> > + struct task_struct *task;
> > +
> > + /* The
On 17:50-20181203, Dan Carpenter wrote:
> The > comparison should be >= or we access one element beyond the end
> of the array.
>
> (The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function
> and it has ->num_valid_queues elements.)
>
> Fixes:
On 17:50-20181203, Dan Carpenter wrote:
> The > comparison should be >= or we access one element beyond the end
> of the array.
>
> (The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function
> and it has ->num_valid_queues elements.)
>
> Fixes:
On Wed, Nov 28, 2018 at 12:25 PM Chen-Yu Tsai wrote:
>
> Hi,
>
> On Thu, Nov 15, 2018 at 5:36 PM Chen-Yu Tsai wrote:
> >
> > Hi everyone,
> >
> > This is v2 of my Broadcom-based Bluetooth controllers on Allwinner SoC-
> > based SBCs series.
> >
> > Changes since v1:
> >
> > - Collected tags
>
On Mon, 03 Dec 2018 16:46:01 +0100,
ayman.baga...@gmail.com wrote:
>
> > > + priv->cdev.name = "platform::micmute";
> > > + priv->cdev.max_brightness = 1;
> > > + priv->cdev.brightness_set_blocking =
> > > huawei_wmi_micmute_led_set;
> > > + priv->cdev.default_trigger = "audio-micmute";
> > > +
On Wed, Nov 28, 2018 at 12:25 PM Chen-Yu Tsai wrote:
>
> Hi,
>
> On Thu, Nov 15, 2018 at 5:36 PM Chen-Yu Tsai wrote:
> >
> > Hi everyone,
> >
> > This is v2 of my Broadcom-based Bluetooth controllers on Allwinner SoC-
> > based SBCs series.
> >
> > Changes since v1:
> >
> > - Collected tags
>
On Mon, 03 Dec 2018 16:46:01 +0100,
ayman.baga...@gmail.com wrote:
>
> > > + priv->cdev.name = "platform::micmute";
> > > + priv->cdev.max_brightness = 1;
> > > + priv->cdev.brightness_set_blocking =
> > > huawei_wmi_micmute_led_set;
> > > + priv->cdev.default_trigger = "audio-micmute";
> > > +
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
wrote:
>
> Hi,
>
> On 2018/11/30 17:16, Stephen Boyd wrote:
> > Quoting Sugaya, Taichi (2018-11-29 04:24:51)
> >> On 2018/11/28 11:01, Stephen Boyd wrote:
> >>> Quoting Sugaya Taichi (2018-11-18 17:01:07)
> create mode 100644
>
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
wrote:
>
> Hi,
>
> On 2018/11/30 17:16, Stephen Boyd wrote:
> > Quoting Sugaya, Taichi (2018-11-29 04:24:51)
> >> On 2018/11/28 11:01, Stephen Boyd wrote:
> >>> Quoting Sugaya Taichi (2018-11-18 17:01:07)
> create mode 100644
>
On Mon, 2018-12-03 at 13:00 +0100, Takashi Iwai wrote:
> On Fri, 30 Nov 2018 00:57:38 +0100,
> Ayman Bagabas wrote:
> > Some of Huawei laptops come with a LED in the micmute key. This
> > patch
> > enables the use of micmute LED for these devices:
> > 1. Matebook X (19e5:3200), (19e5:3201)
> > 2.
On Mon, 2018-12-03 at 13:00 +0100, Takashi Iwai wrote:
> On Fri, 30 Nov 2018 00:57:38 +0100,
> Ayman Bagabas wrote:
> > Some of Huawei laptops come with a LED in the micmute key. This
> > patch
> > enables the use of micmute LED for these devices:
> > 1. Matebook X (19e5:3200), (19e5:3201)
> > 2.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
On Mon, Dec 03, 2018 at 11:40:58PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This small series renames the csi0 and ts0 pin function names to csi and
> ts. This makes the names match the datasheet. As there are only one of
> each type of controller, having a numeral suffix doesn't make sense.
On Mon, Dec 03, 2018 at 11:40:58PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This small series renames the csi0 and ts0 pin function names to csi and
> ts. This makes the names match the datasheet. As there are only one of
> each type of controller, having a numeral suffix doesn't make sense.
On Mon, 2018-12-03 at 13:00 +0100, Takashi Iwai wrote:
> On Fri, 30 Nov 2018 00:57:37 +0100,
> Ayman Bagabas wrote:
> > This driver adds support for missing hotkeys on some Huawei
> > laptops.
> > Laptops such as the Matebook X have non functioning hotkeys.
> > Whereas
> > newer laptops such as
On Mon, 2018-12-03 at 13:00 +0100, Takashi Iwai wrote:
> On Fri, 30 Nov 2018 00:57:37 +0100,
> Ayman Bagabas wrote:
> > This driver adds support for missing hotkeys on some Huawei
> > laptops.
> > Laptops such as the Matebook X have non functioning hotkeys.
> > Whereas
> > newer laptops such as
On Mon, Dec 3, 2018 at 9:58 AM Florian Eckert wrote:
> >> > Btw, is the statement in above email still actual? "...I can fix
> >> > required things."
> >
> >> Yes i will fix your hints tomorrow and send a v6 of my patchset.
> >> Thank you for your hints and time
> >> It would be nice if you
On Mon, Dec 3, 2018 at 9:58 AM Florian Eckert wrote:
> >> > Btw, is the statement in above email still actual? "...I can fix
> >> > required things."
> >
> >> Yes i will fix your hints tomorrow and send a v6 of my patchset.
> >> Thank you for your hints and time
> >> It would be nice if you
Hi everyone,
This small series renames the csi0 and ts0 pin function names to csi and
ts. This makes the names match the datasheet. As there are only one of
each type of controller, having a numeral suffix doesn't make sense.
I'd like to do the rename now while we don't have users nor support
Hi everyone,
This small series renames the csi0 and ts0 pin function names to csi and
ts. This makes the names match the datasheet. As there are only one of
each type of controller, having a numeral suffix doesn't make sense.
I'd like to do the rename now while we don't have users nor support
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
> NAK I get a failure in TTM on init with your x86/mm branch (see attached
> dmesg).
So the good news is that with some additional self-tests I can trivially
reproduce this. The bad news is that an otherwise straight forward
cleanup
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote:
> NAK I get a failure in TTM on init with your x86/mm branch (see attached
> dmesg).
So the good news is that with some additional self-tests I can trivially
reproduce this. The bad news is that an otherwise straight forward
cleanup
* Stephen Boyd [181130 23:52]:
> Quoting Tony Lindgren (2018-11-30 07:37:29)
> > Hi,
> >
> > * Tero Kristo [181130 09:21]:
> > > On 30/11/2018 09:57, Stephen Boyd wrote:
> > > > No that is not preferred. Can the omap2_clk_deny_idle() function be
> > > > integrated closer into the clk framework
* Stephen Boyd [181130 23:52]:
> Quoting Tony Lindgren (2018-11-30 07:37:29)
> > Hi,
> >
> > * Tero Kristo [181130 09:21]:
> > > On 30/11/2018 09:57, Stephen Boyd wrote:
> > > > No that is not preferred. Can the omap2_clk_deny_idle() function be
> > > > integrated closer into the clk framework
Hi Lorenzo,
Lorenzo Pieralisi wrote on Mon, 3 Dec 2018
10:27:08 +:
> [+Rafael, Sudeep]
>
> On Fri, Nov 23, 2018 at 03:18:24PM +0100, Miquel Raynal wrote:
> > Add suspend and resume callbacks. The priority of these are
> > "_noirq()", to workaround early access to the registers done by the
Hi Lorenzo,
Lorenzo Pieralisi wrote on Mon, 3 Dec 2018
10:27:08 +:
> [+Rafael, Sudeep]
>
> On Fri, Nov 23, 2018 at 03:18:24PM +0100, Miquel Raynal wrote:
> > Add suspend and resume callbacks. The priority of these are
> > "_noirq()", to workaround early access to the registers done by the
The offsets for the defined BCR reset registers does not match the hardware
documentation. Update the values to match the hardware documentation.
Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global Clock Control (GCC) driver)
Signed-off-by: Jeffrey Hugo
---
drivers/clk/qcom/gcc-msm8998.c | 38
The offsets for the defined BCR reset registers does not match the hardware
documentation. Update the values to match the hardware documentation.
Fixes: b5f5f525c547 (clk: qcom: Add MSM8998 Global Clock Control (GCC) driver)
Signed-off-by: Jeffrey Hugo
---
drivers/clk/qcom/gcc-msm8998.c | 38
You probably forgot to replace the subject with Josh's proposal.
> module_put() is currently never called in klp_complete_transition() when
> klp_force is set. As a result, we might keep the reference count even when
> klp_enable_patch() fails and klp_cancel_transition() is called.
Correct.
>
You probably forgot to replace the subject with Josh's proposal.
> module_put() is currently never called in klp_complete_transition() when
> klp_force is set. As a result, we might keep the reference count even when
> klp_enable_patch() fails and klp_cancel_transition() is called.
Correct.
>
On 11/27/2018 10:09 PM, Elie Morisse wrote:
> Hi Nehal-bakulchandra,
>
>> There was intention behind to make two separate driver for pci and I2c.
> It has future usecase in our platforms and hence we made modular designed.
> So better to make it two separate driver.
>
> I merged the two
On 11/27/2018 10:09 PM, Elie Morisse wrote:
> Hi Nehal-bakulchandra,
>
>> There was intention behind to make two separate driver for pci and I2c.
> It has future usecase in our platforms and hence we made modular designed.
> So better to make it two separate driver.
>
> I merged the two
On Mon, Dec 03, 2018 at 03:42:41PM +0100, Daniel Lezcano wrote:
On 03/12/2018 15:14, Greg KH wrote:
On Mon, Dec 03, 2018 at 11:31:02AM -0200, Rafael David Tinoco wrote:
Sasha, could you consider including this cherry-picked patchset in v4.14.
Kernel v4.14 might suffer from the following
On Mon, Dec 03, 2018 at 03:42:41PM +0100, Daniel Lezcano wrote:
On 03/12/2018 15:14, Greg KH wrote:
On Mon, Dec 03, 2018 at 11:31:02AM -0200, Rafael David Tinoco wrote:
Sasha, could you consider including this cherry-picked patchset in v4.14.
Kernel v4.14 might suffer from the following
On 2018/12/3 下午7:56, Michal Hocko wrote:
> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
>> There may be cgroup memory overcommitment, it will become
>> even common in the future.
>>
>> Let's enable kswapd to reclaim low-protected memory in case
>> of memory pressure, to mitigate the global direct
On 2018/12/3 下午7:56, Michal Hocko wrote:
> On Mon 03-12-18 16:01:18, Xunlei Pang wrote:
>> There may be cgroup memory overcommitment, it will become
>> even common in the future.
>>
>> Let's enable kswapd to reclaim low-protected memory in case
>> of memory pressure, to mitigate the global direct
MP2 controllers have two separate busses, so may accommodate up to two I2C
adapters. Those adapters are listed in the ACPI namespace with the
"AMDI0011" HID, and probed by a platform driver.
Communication with the MP2 takes place through iomapped registers, or
through DMA for more than 32 bytes
MP2 controllers have two separate busses, so may accommodate up to two I2C
adapters. Those adapters are listed in the ACPI namespace with the
"AMDI0011" HID, and probed by a platform driver.
Communication with the MP2 takes place through iomapped registers, or
through DMA for more than 32 bytes
Hi, Matthew,
On 三, 2018-10-10 at 01:30 -0700, Matthew Garrett wrote:
> Platforms support more DPTF policies than the driver currently
> exposes.
> Add them. This effectively reverts
> 31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs
> without explaining why.
>
I'm going to
Hi, Matthew,
On 三, 2018-10-10 at 01:30 -0700, Matthew Garrett wrote:
> Platforms support more DPTF policies than the driver currently
> exposes.
> Add them. This effectively reverts
> 31908f45a583e8f21db37f402b6e8d5739945afd which removed several UUIDs
> without explaining why.
>
I'm going to
[Re: [PATCH 12/22] mfd: sta2x11: drop unused MODULE_ tags from non-modular
code] On 03/12/2018 (Mon 11:14) Lee Jones wrote:
> On Sun, 02 Dec 2018, Paul Gortmaker wrote:
>
> > The Kconfig currently controlling compilation of this code is:
> >
> > drivers/mfd/Kconfig:config MFD_STA2X11
> >
[Re: [PATCH 12/22] mfd: sta2x11: drop unused MODULE_ tags from non-modular
code] On 03/12/2018 (Mon 11:14) Lee Jones wrote:
> On Sun, 02 Dec 2018, Paul Gortmaker wrote:
>
> > The Kconfig currently controlling compilation of this code is:
> >
> > drivers/mfd/Kconfig:config MFD_STA2X11
> >
On Sat 2018-12-01 23:44:37, Tetsuo Handa wrote:
> On 2018/12/01 0:40, Petr Mladek wrote:
> >> Some examples for console output:
> >>
> >> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
> >> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
> >> [0.299733] [T1]
On Sat 2018-12-01 23:44:37, Tetsuo Handa wrote:
> On 2018/12/01 0:40, Petr Mladek wrote:
> >> Some examples for console output:
> >>
> >> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
> >> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
> >> [0.299733] [T1]
On 2018/12/03 23:14, Petr Mladek wrote:
> Well, IMHO, it does not explain the pagefault above. The copy_to_user()
> could come either from syslog_print() or from syslog_print_all(). They
> both have their own checks that prevent the buf overflow.
>
> The code is tricky but it looks safe now. Is
On 2018/12/03 23:14, Petr Mladek wrote:
> Well, IMHO, it does not explain the pagefault above. The copy_to_user()
> could come either from syslog_print() or from syslog_print_all(). They
> both have their own checks that prevent the buf overflow.
>
> The code is tricky but it looks safe now. Is
On Thu, 29 Nov 2018, Petr Mladek wrote:
> -static int klp_init_patch(struct klp_patch *patch)
> +/* Init operations that must succeed before klp_free_patch() can be called.
> */
> +static int klp_init_patch_before_free(struct klp_patch *patch)
There is no klp_free_patch() now, so the comment is
On Thu, 29 Nov 2018, Petr Mladek wrote:
> -static int klp_init_patch(struct klp_patch *patch)
> +/* Init operations that must succeed before klp_free_patch() can be called.
> */
> +static int klp_init_patch_before_free(struct klp_patch *patch)
There is no klp_free_patch() now, so the comment is
Em Mon, Dec 03, 2018 at 12:18:46PM +, Robert Walker escreveu:
> This patch adds support for generating instruction samples from trace of
> AArch32 programs using the A32 and T32 instruction sets.
>
> T32 has variable 2 or 4 byte instruction size, so the conversion between
> addresses and
Em Mon, Dec 03, 2018 at 12:18:46PM +, Robert Walker escreveu:
> This patch adds support for generating instruction samples from trace of
> AArch32 programs using the A32 and T32 instruction sets.
>
> T32 has variable 2 or 4 byte instruction size, so the conversion between
> addresses and
The > comparison should be >= to prevent reading beyond the end of the
func->template[] array.
(The func->template array is allocated in vexpress_syscfg_regmap_init()
and it has func->num_templates elements.)
Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
Signed-off-by:
The > comparison should be >= to prevent reading beyond the end of the
func->template[] array.
(The func->template array is allocated in vexpress_syscfg_regmap_init()
and it has func->num_templates elements.)
Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells")
Signed-off-by:
On Sat, Nov 24, 2018 at 01:46:34PM -0500, Steven Rostedt wrote:
On Fri, 23 Nov 2018 15:00:11 -0500
Sasha Levin wrote:
What will happen with these is that once Greg's scripts process Linus's
tree he'll end up with this patch series inconsistently backported to
stable trees, which is not what
On 12/3/18 12:43 AM, Wen Yang wrote:
The null check on >cmap is redundant since cmap is a struct
inside fb_info and can never be null, so the check is always true.
we may remove it.
Signed-off-by: Wen Yang
Acked-by: Timur Tabi
On Sat, Nov 24, 2018 at 01:46:34PM -0500, Steven Rostedt wrote:
On Fri, 23 Nov 2018 15:00:11 -0500
Sasha Levin wrote:
What will happen with these is that once Greg's scripts process Linus's
tree he'll end up with this patch series inconsistently backported to
stable trees, which is not what
On 12/3/18 12:43 AM, Wen Yang wrote:
The null check on >cmap is redundant since cmap is a struct
inside fb_info and can never be null, so the check is always true.
we may remove it.
Signed-off-by: Wen Yang
Acked-by: Timur Tabi
On Sat, Dec 1, 2018 at 9:22 PM Manfred Spraul wrote:
>
> Hi Dmitry,
>
> On 11/30/18 6:58 PM, Dmitry Vyukov wrote:
> > On Thu, Nov 29, 2018 at 9:13 AM, Manfred Spraul
> > wrote:
> >> Hello together,
> >>
> >> On 11/27/18 4:52 PM, syzbot wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following
On Sat, Dec 1, 2018 at 9:22 PM Manfred Spraul wrote:
>
> Hi Dmitry,
>
> On 11/30/18 6:58 PM, Dmitry Vyukov wrote:
> > On Thu, Nov 29, 2018 at 9:13 AM, Manfred Spraul
> > wrote:
> >> Hello together,
> >>
> >> On 11/27/18 4:52 PM, syzbot wrote:
> >>
> >> Hello,
> >>
> >> syzbot found the following
On 03/12/2018 15:50, Anup Patel wrote:
> On Mon, Dec 3, 2018 at 6:29 PM Daniel Lezcano
> wrote:
>>
>> On 03/12/2018 13:35, Anup Patel wrote:
>>> Currently, we don't have a sched_clock registered for RISC-V systems.
>>> This means Linux time keeping will use jiffies (running at HZ) as the
>>>
On 03/12/2018 15:50, Anup Patel wrote:
> On Mon, Dec 3, 2018 at 6:29 PM Daniel Lezcano
> wrote:
>>
>> On 03/12/2018 13:35, Anup Patel wrote:
>>> Currently, we don't have a sched_clock registered for RISC-V systems.
>>> This means Linux time keeping will use jiffies (running at HZ) as the
>>>
On Mon, Dec 3, 2018 at 6:29 PM Daniel Lezcano wrote:
>
> On 03/12/2018 13:35, Anup Patel wrote:
> > Currently, we don't have a sched_clock registered for RISC-V systems.
> > This means Linux time keeping will use jiffies (running at HZ) as the
> > default sched_clock.
> >
> > To avoid this, we
On Mon, Dec 3, 2018 at 6:29 PM Daniel Lezcano wrote:
>
> On 03/12/2018 13:35, Anup Patel wrote:
> > Currently, we don't have a sched_clock registered for RISC-V systems.
> > This means Linux time keeping will use jiffies (running at HZ) as the
> > default sched_clock.
> >
> > To avoid this, we
The > comparison should be >= or we access one element beyond the end
of the array.
(The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function
and it has ->num_valid_queues elements.)
Fixes: a2b79838b891 ("mailbox: ti-msgmgr: Add support for Secure Proxy")
Signed-off-by: Dan
The > comparison should be >= or we access one element beyond the end
of the array.
(The inst->qinsts[] array is allocated in the ti_msgmgr_probe() function
and it has ->num_valid_queues elements.)
Fixes: a2b79838b891 ("mailbox: ti-msgmgr: Add support for Secure Proxy")
Signed-off-by: Dan
We recently moved the test size tests around but it means we need to
adjust the error handling as well or we leak the "pq_coefs" memory. I
updated the label name to reflect that we're freeing coefs.
Fixes: 787d3083caf8 ("dmaengine: dmatest: move size checks earlier in function")
Signed-off-by:
We recently moved the test size tests around but it means we need to
adjust the error handling as well or we leak the "pq_coefs" memory. I
updated the label name to reflect that we're freeing coefs.
Fixes: 787d3083caf8 ("dmaengine: dmatest: move size checks earlier in function")
Signed-off-by:
On 2018/12/3 下午7:54, Michal Hocko wrote:
> On Mon 03-12-18 16:01:17, Xunlei Pang wrote:
>> When usage exceeds min, min usage should be min other than 0.
>> Apply the same for low.
>
> Why? What is the actual problem.
children_min_usage tracks the total children usages under min,
it's natural
On 2018/12/3 下午7:54, Michal Hocko wrote:
> On Mon 03-12-18 16:01:17, Xunlei Pang wrote:
>> When usage exceeds min, min usage should be min other than 0.
>> Apply the same for low.
>
> Why? What is the actual problem.
children_min_usage tracks the total children usages under min,
it's natural
On Mon 2018-12-03 15:17:37, Michal Hocko wrote:
> On Mon 03-12-18 15:14:59, Pavel Machek wrote:
> > On Mon 2018-12-03 14:53:51, Michal Hocko wrote:
> > > On Mon 03-12-18 14:10:06, Pavel Machek wrote:
> > > > On Mon 2018-12-03 13:38:57, Michal Hocko wrote:
> > > > > On Mon 03-12-18 13:31:49, Oleg
On Mon 2018-12-03 15:17:37, Michal Hocko wrote:
> On Mon 03-12-18 15:14:59, Pavel Machek wrote:
> > On Mon 2018-12-03 14:53:51, Michal Hocko wrote:
> > > On Mon 03-12-18 14:10:06, Pavel Machek wrote:
> > > > On Mon 2018-12-03 13:38:57, Michal Hocko wrote:
> > > > > On Mon 03-12-18 13:31:49, Oleg
On 03/12/2018 15:14, Greg KH wrote:
> On Mon, Dec 03, 2018 at 11:31:02AM -0200, Rafael David Tinoco wrote:
>> Sasha, could you consider including this cherry-picked patchset in v4.14.
>>
>> Kernel v4.14 might suffer from the following unbalanced enablement for the
>> board Hikey 960:
>>
>> Nov 5
On 03/12/2018 15:14, Greg KH wrote:
> On Mon, Dec 03, 2018 at 11:31:02AM -0200, Rafael David Tinoco wrote:
>> Sasha, could you consider including this cherry-picked patchset in v4.14.
>>
>> Kernel v4.14 might suffer from the following unbalanced enablement for the
>> board Hikey 960:
>>
>> Nov 5
On Sun, Dec 2, 2018 at 9:09 PM Greg KH wrote:
>
> On Sun, Dec 02, 2018 at 08:10:16AM -0800, Christoph Hellwig wrote:
> > As someone who has done xfs stable backports for a while I really don't
> > think the autoselection is helpful at all.
>
> autoselection for xfs patches has been turned off for
On Sun, Dec 2, 2018 at 9:09 PM Greg KH wrote:
>
> On Sun, Dec 02, 2018 at 08:10:16AM -0800, Christoph Hellwig wrote:
> > As someone who has done xfs stable backports for a while I really don't
> > think the autoselection is helpful at all.
>
> autoselection for xfs patches has been turned off for
PID: 1 at drivers/gpio/gpiolib-devres.c:336
s2mps11_pmic_probe+0x1c4/0x49c
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.20.0-rc5-next-20181203-00020-gf6d64d46ca8c #1156
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[]
Hi Matthew,
This seems terribly complicated. You run through i_pages, record the
indices of the swap entries, then go back and look them up again by
calling shmem_getpage() which calls the incredibly complex 300 line
shmem_getpage_gfp().
Can we refactor shmem_getpage_gfp() to skip some of
PID: 1 at drivers/gpio/gpiolib-devres.c:336
s2mps11_pmic_probe+0x1c4/0x49c
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted
4.20.0-rc5-next-20181203-00020-gf6d64d46ca8c #1156
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[]
Hi Matthew,
This seems terribly complicated. You run through i_pages, record the
indices of the swap entries, then go back and look them up again by
calling shmem_getpage() which calls the incredibly complex 300 line
shmem_getpage_gfp().
Can we refactor shmem_getpage_gfp() to skip some of
The refactoring is needed for the new client in devfreq: suspend.
To avoid code duplication, move it to the new local function
devfreq_set_target.
The patch is based on earlier work by Tobias Jakobi.
Suggested-by: Tobias Jakobi
Suggested-by: Chanwoo Choi
Signed-off-by: Lukasz Luba
---
Hello,
kbuild test robot wrote on Sat, 1 Dec 2018 08:29:05
+0800:
> Hi Miquel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on clk/clk-next]
> [also build test ERROR on v4.20-rc4 next-20181130]
> [if your patch is applied to the wrong git tree, please drop us a
Hi all,
This v2 patch set aims to address the issue with devfreq devices' frequency
during suspend/resume. It extends suspend/resume by calls to Devfreq
framework. In the devfreq framework there is a small refactoring to avoid
code duplication in changging frequency (patch 1) and there are
The refactoring is needed for the new client in devfreq: suspend.
To avoid code duplication, move it to the new local function
devfreq_set_target.
The patch is based on earlier work by Tobias Jakobi.
Suggested-by: Tobias Jakobi
Suggested-by: Chanwoo Choi
Signed-off-by: Lukasz Luba
---
901 - 1000 of 1632 matches
Mail list logo
