Hi Linus,
First rc pull request
This is a bit later than usual for our first -rc but I'm not seeing
anything worry-some in the RDMA tree right now. Quiet so far this -rc
cycle, only a few internal driver related bugs and a small series
fixing ODP bugs found by more advanced testing.
The
Hi Linus,
First rc pull request
This is a bit later than usual for our first -rc but I'm not seeing
anything worry-some in the RDMA tree right now. Quiet so far this -rc
cycle, only a few internal driver related bugs and a small series
fixing ODP bugs found by more advanced testing.
The
On Thu, Nov 29, 2018 at 05:41:35PM -0500, Waiman Long wrote:
> When a kernel module is repeatedly load and unload, it will eventually
> exhaust the lockdep entries resulting in a bug message. This is a use
> case that the current lockdep code cannot support.
>
> This patchset tracks the number of
> Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
>
> ср, 28 нояб. 2018 г. в 15:43, Long Li :
> >
> > > Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
> > >
> > > Hi Long,
> > >
> > > Please find my comments below.
> > >
> > >
> > > ср, 31 окт. 2018 г. в
On Thu, Nov 29, 2018 at 05:41:35PM -0500, Waiman Long wrote:
> When a kernel module is repeatedly load and unload, it will eventually
> exhaust the lockdep entries resulting in a bug message. This is a use
> case that the current lockdep code cannot support.
>
> This patchset tracks the number of
> Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
>
> ср, 28 нояб. 2018 г. в 15:43, Long Li :
> >
> > > Subject: Re: [Patch v4 1/3] CIFS: Add support for direct I/O read
> > >
> > > Hi Long,
> > >
> > > Please find my comments below.
> > >
> > >
> > > ср, 31 окт. 2018 г. в
On 29.11.2018 09:12, Kunihiko Hayashi wrote:
> Even though the link is down before entering hibernation,
> there is an issue that the network interface always links up after resuming
> from hibernation.
>
> The phydev->state is PHY_READY before enabling the network interface, so
> the link is
On 29.11.2018 09:12, Kunihiko Hayashi wrote:
> Even though the link is down before entering hibernation,
> there is an issue that the network interface always links up after resuming
> from hibernation.
>
> The phydev->state is PHY_READY before enabling the network interface, so
> the link is
On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> >
> > > > (like pointing
On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> >
> > > > (like pointing
Quoting Janek Kotas (2018-11-15 00:27:15)
> Thanks for the reply.
> Jan
>
> > On 14 Nov 2018, at 23:19, Stephen Boyd wrote:
> >
> > Quoting Janek Kotas (2018-11-14 07:24:39)
> >> This patch adds a driver for Fixed MMIO clock.
> >> The driver reads a clock frequency value from a single 32-bit
Quoting Janek Kotas (2018-11-15 00:27:15)
> Thanks for the reply.
> Jan
>
> > On 14 Nov 2018, at 23:19, Stephen Boyd wrote:
> >
> > Quoting Janek Kotas (2018-11-14 07:24:39)
> >> This patch adds a driver for Fixed MMIO clock.
> >> The driver reads a clock frequency value from a single 32-bit
On Thu, Nov 29, 2018 at 02:25:33PM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote:
> >
> > On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Nov 29, 2018 at
On Thu, Nov 29, 2018 at 02:25:33PM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote:
> >
> > On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Nov 29, 2018 at
(+)
--- linux-next-20181129.orig/drivers/spi/spi-at91-usart.c
+++ linux-next-20181129/drivers/spi/spi-at91-usart.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
(+)
--- linux-next-20181129.orig/drivers/spi/spi-at91-usart.c
+++ linux-next-20181129/drivers/spi/spi-at91-usart.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
>
>> Possibly I misunderstood you, but I don't think we want to copy-up on
>> permission denial, as that would still allow the mounter to read/write
>> special files or execute regular files to
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
>
>> Possibly I misunderstood you, but I don't think we want to copy-up on
>> permission denial, as that would still allow the mounter to read/write
>> special files or execute regular files to
On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > > On Thu, Nov 29, 2018 at
On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > > On Thu, Nov 29, 2018 at
This patch removes the linux-soc mailing list from the Qualcomm SoC
entry. We use the linux-msm and there is no need to have the second
one and this clears the list for use by others.
Signed-off-by: Andy Gross
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS
This patch removes the linux-soc mailing list from the Qualcomm SoC
entry. We use the linux-msm and there is no need to have the second
one and this clears the list for use by others.
Signed-off-by: Andy Gross
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS
From: Martin Schiller
Date: Tue, 27 Nov 2018 09:50:28 +0100
> o x25_find_listener(): the compare for the null_x25_address was wrong.
>We have to check the x25_addr of the listener socket instead of the
>x25_addr of the incomming call.
>
> o x25_bind(): it was not possible to bind a
From: Martin Schiller
Date: Tue, 27 Nov 2018 09:50:28 +0100
> o x25_find_listener(): the compare for the null_x25_address was wrong.
>We have to check the x25_addr of the listener socket instead of the
>x25_addr of the incomming call.
>
> o x25_bind(): it was not possible to bind a
When a kernel module is unloaded, all the lock classes associated with
that kernel module will be zapped. Unfortunately the corresponding
lockdep entries in stack_trace[], list_entries[], lock_classes[],
lock_chains[] and chain_hlocks[] are not reusable without greatly
complicating the existing
When a kernel module is unloaded, all the lock classes associated with
that kernel module will be zapped. Unfortunately the corresponding
lockdep entries in stack_trace[], list_entries[], lock_classes[],
lock_chains[] and chain_hlocks[] are not reusable without greatly
complicating the existing
On Thu, Nov 29, 2018 at 01:47:56PM +0100, Greg KH wrote:
> On Thu, Nov 29, 2018 at 11:14:59PM +1100, Dave Chinner wrote:
> >
> > Cherry picking only one of the 50-odd patches we've committed into
> > late 4.19 and 4.20 kernels to fix the problems we've found really
> > seems like asking for
On Thu, Nov 29, 2018 at 01:47:56PM +0100, Greg KH wrote:
> On Thu, Nov 29, 2018 at 11:14:59PM +1100, Dave Chinner wrote:
> >
> > Cherry picking only one of the 50-odd patches we've committed into
> > late 4.19 and 4.20 kernels to fix the problems we've found really
> > seems like asking for
On 29 November 2018 7:41:31 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.19.6 release.
>There are 110 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 know.
>
On Thu, Nov 29, 2018 at 04:36:00PM -0600, Andy Gross wrote:
> On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> > We need to check the call to cmd_db_read_aux_data() for the error case,
> > so that we don't continue and use potentially uninitialized values for
> > 'pri_count' and
On Thu, Nov 29, 2018 at 04:36:00PM -0600, Andy Gross wrote:
> On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> > We need to check the call to cmd_db_read_aux_data() for the error case,
> > so that we don't continue and use potentially uninitialized values for
> > 'pri_count' and
On 29 November 2018 7:41:31 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.19.6 release.
>There are 110 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 know.
>
On Thu, Nov 29, 2018 at 02:36:50PM +0200, Amir Goldstein wrote:
> > Same again - what's the test plan for these cherry-picked data
> > corruption fixes?
> >
>
> Dave,
>
> Just to check if we are on the same page, if this was the test plan:
> https://www.spinics.net/lists/linux-xfs/msg20639.html
On Thu, Nov 29, 2018 at 02:36:50PM +0200, Amir Goldstein wrote:
> > Same again - what's the test plan for these cherry-picked data
> > corruption fixes?
> >
>
> Dave,
>
> Just to check if we are on the same page, if this was the test plan:
> https://www.spinics.net/lists/linux-xfs/msg20639.html
When a kernel module is repeatedly load and unload, it will eventually
exhaust the lockdep entries resulting in a bug message. This is a use
case that the current lockdep code cannot support.
This patchset tracks the number of zapped classes and print a warning if
too many lockdep entries are
There are some #else and #endif preprocessor directives that are hard
to see where the corresponding #if*'s are when they are more than a
page away. To make the code easier to read, those #else and #endif's
are now properly annotated.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 16
When a kernel module is repeatedly load and unload, it will eventually
exhaust the lockdep entries resulting in a bug message. This is a use
case that the current lockdep code cannot support.
This patchset tracks the number of zapped classes and print a warning if
too many lockdep entries are
There are some #else and #endif preprocessor directives that are hard
to see where the corresponding #if*'s are when they are more than a
page away. To make the code easier to read, those #else and #endif's
are now properly annotated.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 16
On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> We need to check the call to cmd_db_read_aux_data() for the error case,
> so that we don't continue and use potentially uninitialized values for
> 'pri_count' and 'sec_count'. Otherwise, we get the following compiler
> warnings:
>
>
On Thu, Nov 29, 2018 at 08:38:26AM -0800, Stephen Boyd wrote:
> We need to check the call to cmd_db_read_aux_data() for the error case,
> so that we don't continue and use potentially uninitialized values for
> 'pri_count' and 'sec_count'. Otherwise, we get the following compiler
> warnings:
>
>
Hi Kevin,
On Thu, Nov 29, 2018 at 1:30 AM Kevin Hilman wrote:
>
> Martin Blumenstingl writes:
>
> > Some Meson8b boards (Odroid-C1, EC-100) use a PWM regulator which is the
> > voltage supply of the CPU cores (this regulator is typically called
> > "VCCK").
> > Now that we are preparing support
Hi Kevin,
On Thu, Nov 29, 2018 at 1:30 AM Kevin Hilman wrote:
>
> Martin Blumenstingl writes:
>
> > Some Meson8b boards (Odroid-C1, EC-100) use a PWM regulator which is the
> > voltage supply of the CPU cores (this regulator is typically called
> > "VCCK").
> > Now that we are preparing support
Hi Ulf,
On Thu, Nov 29 2018 at 10:50 -0700, Ulf Hansson wrote:
When the hierarchical CPU topology is used and when a CPU has been put
offline (hotplug), that same CPU prevents its PM domain and thus also
potential master PM domains, from being powered off. This is because genpd
observes the
Hi Ulf,
On Thu, Nov 29 2018 at 10:50 -0700, Ulf Hansson wrote:
When the hierarchical CPU topology is used and when a CPU has been put
offline (hotplug), that same CPU prevents its PM domain and thus also
potential master PM domains, from being powered off. This is because genpd
observes the
On Thu, Nov 29, 2018 at 2:11 PM Enric Balletbo i Serra
wrote:
>
> Hi,
>
> On 29/11/18 8:55, Greg Kroah-Hartman wrote:
> > On Wed, Nov 28, 2018 at 05:17:22PM -0800, Guenter Roeck wrote:
> >> Hi Greg,
> >>
> >> On Tue, Nov 27, 2018 at 9:52 AM Greg Kroah-Hartman
> >> wrote:
> >>>
> >>> On Tue, Nov
On Thu, Nov 29, 2018 at 2:11 PM Enric Balletbo i Serra
wrote:
>
> Hi,
>
> On 29/11/18 8:55, Greg Kroah-Hartman wrote:
> > On Wed, Nov 28, 2018 at 05:17:22PM -0800, Guenter Roeck wrote:
> >> Hi Greg,
> >>
> >> On Tue, Nov 27, 2018 at 9:52 AM Greg Kroah-Hartman
> >> wrote:
> >>>
> >>> On Tue, Nov
On Thu, Nov 29, 2018 at 5:07 AM Ondrej Mosnacek wrote:
>
> On Wed, Nov 28, 2018 at 10:52 PM Paul Moore wrote:
> > On Tue, Nov 27, 2018 at 6:50 AM Stephen Rothwell
> > wrote:
> > > Hi Ondrej,
> > >
> > > On Tue, 27 Nov 2018 09:53:32 +0100 Ondrej Mosnacek
> > > wrote:
> > > >
> > > > Hm...
On Thu, Nov 29, 2018 at 5:07 AM Ondrej Mosnacek wrote:
>
> On Wed, Nov 28, 2018 at 10:52 PM Paul Moore wrote:
> > On Tue, Nov 27, 2018 at 6:50 AM Stephen Rothwell
> > wrote:
> > > Hi Ondrej,
> > >
> > > On Tue, 27 Nov 2018 09:53:32 +0100 Ondrej Mosnacek
> > > wrote:
> > > >
> > > > Hm...
On Thu, Nov 29, 2018 at 02:24:52PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> > wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > > wrote:
> > > >
> > > > In contrast,
On Thu, Nov 29, 2018 at 02:24:52PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> > wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > > wrote:
> > > >
> > > > In contrast,
On Thu, Nov 29, 2018 at 01:34:21PM -0800, Davidlohr Bueso wrote:
> I messed up something such that waiman was not in the thread. Ccing.
>
> > On Thu, 29 Nov 2018, Waiman Long wrote:
> >
> > > That can be costly for x86 which will now have 2 locked instructions.
> >
> > Yeah, and when used as an
On Thu, Nov 29, 2018 at 01:34:21PM -0800, Davidlohr Bueso wrote:
> I messed up something such that waiman was not in the thread. Ccing.
>
> > On Thu, 29 Nov 2018, Waiman Long wrote:
> >
> > > That can be costly for x86 which will now have 2 locked instructions.
> >
> > Yeah, and when used as an
On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > > (like pointing IP at a stub that retpolines to the target by reading
> > > the function
Move #clock-cells into the child node for instances of the qcom-qmp-phy
nodes, and set it to zero, in accordance with the proper bindings. PHYs
that don't provide clocks don't have #clock-cells, and so are left alone.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > > (like pointing IP at a stub that retpolines to the target by reading
> > > the function
Move #clock-cells into the child node for instances of the qcom-qmp-phy
nodes, and set it to zero, in accordance with the proper bindings. PHYs
that don't provide clocks don't have #clock-cells, and so are left alone.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
Register a simple clock provider for the PHY pipe clock sources so that
device tree users can point at these clocks via phandles to the lane
nodes.
Signed-off-by: Evan Green
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
The phy-qcom-qmp bindings specified #clock-cells as 1. This was never used
because of_clk_add_provider() was never called, so there was no way anybody
could reference these clocks from DT. Furthermore, even if they could be
accessed, the bindings never specified what should go in that additional
Move #clock-cells into the child node and set it to 0 to conform to the
proper binding specification.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
Register a simple clock provider for the PHY pipe clock sources so that
device tree users can point at these clocks via phandles to the lane
nodes.
Signed-off-by: Evan Green
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
The phy-qcom-qmp bindings specified #clock-cells as 1. This was never used
because of_clk_add_provider() was never called, so there was no way anybody
could reference these clocks from DT. Furthermore, even if they could be
accessed, the bindings never specified what should go in that additional
Move #clock-cells into the child node and set it to 0 to conform to the
proper binding specification.
Signed-off-by: Evan Green
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
This series fixes the QMP PHY bindings, which had specified #clock-cells
in the parent node, and had set it to 1. Putting it in the parent node is
wrong because the clock providers are the child nodes, so this change
moves it there. Having it set to 1 is also wrong, since nothing is ever
specified
This series fixes the QMP PHY bindings, which had specified #clock-cells
in the parent node, and had set it to 1. Putting it in the parent node is
wrong because the clock providers are the child nodes, so this change
moves it there. Having it set to 1 is also wrong, since nothing is ever
specified
Hi,
On Wed, Nov 28, 2018 at 3:55 PM Ryan Case wrote:
> @@ -465,9 +470,19 @@ static void qcom_geni_serial_console_write(struct
> console *co, const char *s,
> }
> writel_relaxed(M_CMD_CANCEL_EN, uport->membase +
>
On Thu, 29 Nov 2018 16:53:30 +
Catalin Marinas wrote:
> On Thu, Nov 29, 2018 at 02:39:33PM +0900, Masami Hiramatsu wrote:
> > Since commit 4378a7d4be30 ("arm64: implement syscall wrappers")
> > introduced "__arm64_" prefix to all syscall wrapper symbols in
> > sys_call_table, syscall tracer
Hi,
On Wed, Nov 28, 2018 at 3:55 PM Ryan Case wrote:
> @@ -465,9 +470,19 @@ static void qcom_geni_serial_console_write(struct
> console *co, const char *s,
> }
> writel_relaxed(M_CMD_CANCEL_EN, uport->membase +
>
On Thu, 29 Nov 2018 16:53:30 +
Catalin Marinas wrote:
> On Thu, Nov 29, 2018 at 02:39:33PM +0900, Masami Hiramatsu wrote:
> > Since commit 4378a7d4be30 ("arm64: implement syscall wrappers")
> > introduced "__arm64_" prefix to all syscall wrapper symbols in
> > sys_call_table, syscall tracer
Hi,
On 29/11/18 8:55, Greg Kroah-Hartman wrote:
> On Wed, Nov 28, 2018 at 05:17:22PM -0800, Guenter Roeck wrote:
>> Hi Greg,
>>
>> On Tue, Nov 27, 2018 at 9:52 AM Greg Kroah-Hartman
>> wrote:
>>>
>>> On Tue, Nov 27, 2018 at 09:29:38AM -0800, Guenter Roeck wrote:
Hi Enric,
On Tue,
Hi,
On 29/11/18 8:55, Greg Kroah-Hartman wrote:
> On Wed, Nov 28, 2018 at 05:17:22PM -0800, Guenter Roeck wrote:
>> Hi Greg,
>>
>> On Tue, Nov 27, 2018 at 9:52 AM Greg Kroah-Hartman
>> wrote:
>>>
>>> On Tue, Nov 27, 2018 at 09:29:38AM -0800, Guenter Roeck wrote:
Hi Enric,
On Tue,
On Thu, 29 Nov 2018 14:54:16 -0700
shuah wrote:
> On 11/29/18 2:20 PM, Thomas Gleixner wrote:
> > On Mon, 12 Nov 2018, Thomas Gleixner wrote:
> >
> > Polite reminder
>
> Thanks for the reminder.
>
> >
> >> While GPL2.0 looks about right, the correct and valid identifiers for GPL
> >> v2
On Thu, 29 Nov 2018 14:54:16 -0700
shuah wrote:
> On 11/29/18 2:20 PM, Thomas Gleixner wrote:
> > On Mon, 12 Nov 2018, Thomas Gleixner wrote:
> >
> > Polite reminder
>
> Thanks for the reminder.
>
> >
> >> While GPL2.0 looks about right, the correct and valid identifiers for GPL
> >> v2
On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> + workspace = kmalloc(unzipped_len + record->ecc_notice_size,
> >
> > Should tihs be unzipped_len +
On Tue, Nov 13, 2018 at 11:56 PM Kees Cook wrote:
> On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes wrote:
> > On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
> >> + workspace = kmalloc(unzipped_len + record->ecc_notice_size,
> >
> > Should tihs be unzipped_len +
On Thu, Nov 29, 2018 at 01:34:05PM -0500, Waiman Long wrote:
> That will certainly work for x86. However, I am not sure if that will be
> optimal for arm and powerpc.
smp_mb__before_atomic()
cmpxchg_relaxed()
works. Also see pv_kick_node()'s commit:
34d54f3d6917
On Thu, Nov 29, 2018 at 01:34:05PM -0500, Waiman Long wrote:
> That will certainly work for x86. However, I am not sure if that will be
> optimal for arm and powerpc.
smp_mb__before_atomic()
cmpxchg_relaxed()
works. Also see pv_kick_node()'s commit:
34d54f3d6917
9fd680d0fafd ("clk: imx: add fractional PLL output clock")
I have used the clk tree from next-20181129 for today.
--
Cheers,
Stephen Rothwell
pgpmqRfPkAgc5.pgp
Description: OpenPGP digital signature
9fd680d0fafd ("clk: imx: add fractional PLL output clock")
I have used the clk tree from next-20181129 for today.
--
Cheers,
Stephen Rothwell
pgpmqRfPkAgc5.pgp
Description: OpenPGP digital signature
On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> > (like pointing IP at a stub that retpolines to the target by reading
> > the function pointer, a la the unoptimizable version), then okay, I
> > guess, with only
On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> > (like pointing IP at a stub that retpolines to the target by reading
> > the function pointer, a la the unoptimizable version), then okay, I
> > guess, with only
LTP proc01 testcase has been observed to rarely trigger crashes
on arm64:
page_mapped+0x78/0xb4
stable_page_flags+0x27c/0x338
kpageflags_read+0xfc/0x164
proc_reg_read+0x7c/0xb8
__vfs_read+0x58/0x178
vfs_read+0x90/0x14c
SyS_read+0x60/0xc0
Issue is that page_mapped()
LTP proc01 testcase has been observed to rarely trigger crashes
on arm64:
page_mapped+0x78/0xb4
stable_page_flags+0x27c/0x338
kpageflags_read+0xfc/0x164
proc_reg_read+0x7c/0xb8
__vfs_read+0x58/0x178
vfs_read+0x90/0x14c
SyS_read+0x60/0xc0
Issue is that page_mapped()
On 11/29/18 2:20 PM, Thomas Gleixner wrote:
On Mon, 12 Nov 2018, Thomas Gleixner wrote:
Polite reminder
Thanks for the reminder.
While GPL2.0 looks about right, the correct and valid identifiers for GPL v2
only code are 'GPL-2.0' or 'GPL-2.0-only'.
Signed-off-by: Thomas Gleixner
Cc:
On 11/29/18 2:20 PM, Thomas Gleixner wrote:
On Mon, 12 Nov 2018, Thomas Gleixner wrote:
Polite reminder
Thanks for the reminder.
While GPL2.0 looks about right, the correct and valid identifiers for GPL v2
only code are 'GPL-2.0' or 'GPL-2.0-only'.
Signed-off-by: Thomas Gleixner
Cc:
Quoting Aisheng DONG (2018-11-28 23:46:41)
> > -Original Message-
> > From: Stephen Boyd [mailto:sb...@kernel.org]
> [...]
> > >
> > > Changes since v12:
> > > * replaced the division in clk_pll_recalc_rate in clk-frac
> > >with do_div as suggested by Stephen
> > >
> > > Abel Vesa
Quoting Aisheng DONG (2018-11-28 23:46:41)
> > -Original Message-
> > From: Stephen Boyd [mailto:sb...@kernel.org]
> [...]
> > >
> > > Changes since v12:
> > > * replaced the division in clk_pll_recalc_rate in clk-frac
> > >with do_div as suggested by Stephen
> > >
> > > Abel Vesa
Quoting Abel Vesa (2018-11-13 08:19:58)
> From: Lucas Stach
>
> This is a new fractional clock type introduced on i.MX8.
>
> The description of this fractional clock can be found here:
>
> https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
>
> Signed-off-by: Lucas Stach
>
Quoting Abel Vesa (2018-11-13 08:19:59)
> From: Lucas Stach
>
> The SCCG is a new PLL type introduced on i.MX8.
>
> The description of this SCCG clock can be found here:
>
> https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
>
> Signed-off-by: Lucas Stach
> Signed-off-by:
Quoting Abel Vesa (2018-11-13 08:20:00)
> Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
> divider, the idea here is to combine all of those into one composite clock,
> but we need to deal with both predivider and divider at the same time and
> therefore we add the
Quoting Abel Vesa (2018-11-13 08:20:01)
> Add driver for the Clock Control Module found on i.MX8MQ.
>
> Signed-off-by: Anson Huang
> Signed-off-by: Bai Ping
> Signed-off-by: Lucas Stach
> Signed-off-by: Abel Vesa
> Reviewed-by: Sascha Hauer
> ---
Applied to clk-next
Quoting Abel Vesa (2018-11-13 08:19:58)
> From: Lucas Stach
>
> This is a new fractional clock type introduced on i.MX8.
>
> The description of this fractional clock can be found here:
>
> https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
>
> Signed-off-by: Lucas Stach
>
Quoting Abel Vesa (2018-11-13 08:19:59)
> From: Lucas Stach
>
> The SCCG is a new PLL type introduced on i.MX8.
>
> The description of this SCCG clock can be found here:
>
> https://www.nxp.com/docs/en/reference-manual/IMX8MDQLQRM.pdf#page=834
>
> Signed-off-by: Lucas Stach
> Signed-off-by:
Quoting Abel Vesa (2018-11-13 08:20:00)
> Since a lot of clocks on imx8m are formed by a mux, gate, predivider and
> divider, the idea here is to combine all of those into one composite clock,
> but we need to deal with both predivider and divider at the same time and
> therefore we add the
Quoting Abel Vesa (2018-11-13 08:20:01)
> Add driver for the Clock Control Module found on i.MX8MQ.
>
> Signed-off-by: Anson Huang
> Signed-off-by: Bai Ping
> Signed-off-by: Lucas Stach
> Signed-off-by: Abel Vesa
> Reviewed-by: Sascha Hauer
> ---
Applied to clk-next
Quoting Abel Vesa (2018-11-13 08:19:57)
> From: Lucas Stach
>
> This adds the binding for the i.MX8MQ Clock Controller Module.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Abel Vesa
> Reviewed-by: Rob Herring
> ---
Applied to clk-next
Quoting Abel Vesa (2018-11-13 08:19:57)
> From: Lucas Stach
>
> This adds the binding for the i.MX8MQ Clock Controller Module.
>
> Signed-off-by: Lucas Stach
> Signed-off-by: Abel Vesa
> Reviewed-by: Rob Herring
> ---
Applied to clk-next
On 29 November 2018 7:41:25 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.4.166 release.
>There are 86 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 know.
>
On 29 November 2018 7:41:25 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.4.166 release.
>There are 86 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 know.
>
On 29 November 2018 7:41:18 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.128 release.
>There are 83 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 know.
>
On 29 November 2018 7:41:18 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.128 release.
>There are 83 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 know.
>
501 - 600 of 2748 matches
Mail list logo
