On Tue, Aug 28, 2018 at 4:36 AM, Atish Patra wrote:
> This patch series implements following smp related features.
> Some of the work has been inspired from ARM64.
>
> 1. Decouple linux logical cpu ids from hardware cpu id
> 2. Support cpu hotplug.
>
> Tested on QEMU & HighFive Unleashed board
On Tue, Aug 28, 2018 at 3:17 PM Sunil Kovvuri wrote:
> On Tue, Aug 28, 2018 at 6:27 PM Arnd Bergmann wrote:
> > On Tue, Aug 28, 2018 at 2:42 PM Sunil Kovvuri
> > wrote:
> > > On Tue, Aug 28, 2018 at 5:39 PM Arnd Bergmann wrote:
> > > > On Tue, Aug 28, 2018 at 12:58 PM wrote:
> > >
> > > This
On Thu, Aug 30, 2018 at 03:25:42PM +0200, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Feng Tang wrote:
> > On Thu, Aug 30, 2018 at 03:05:31PM +0200, Thomas Gleixner wrote:
> > > > Those [_text, __bss_stop] is not able to be used by alloc_bootmem().
> > > > And I
> > > > only got this patch, and
On Thu, Aug 30, 2018 at 03:25:42PM +0200, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Feng Tang wrote:
> > On Thu, Aug 30, 2018 at 03:05:31PM +0200, Thomas Gleixner wrote:
> > > > Those [_text, __bss_stop] is not able to be used by alloc_bootmem().
> > > > And I
> > > > only got this patch, and
On Thu, Aug 30, 2018 at 03:04:39PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 12:55:30PM +0200, Siegfried Metz wrote:
> > Dear kernel developers,
> >
> > since mainline kernel 4.18 (up to the latest mainline kernel 4.18.5)
> > Intel Core 2 Duo processors are affected by boot stalling
On Thu, Aug 30, 2018 at 03:04:39PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 12:55:30PM +0200, Siegfried Metz wrote:
> > Dear kernel developers,
> >
> > since mainline kernel 4.18 (up to the latest mainline kernel 4.18.5)
> > Intel Core 2 Duo processors are affected by boot stalling
Hello Sébastien,
Am 30.08.2018 um 15:25 schrieb Sébastien Szymanski:
Hi,
On 08/30/2018 02:47 PM, Heiko Schocher wrote:
on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based
Hello Sébastien,
Am 30.08.2018 um 15:25 schrieb Sébastien Szymanski:
Hi,
On 08/30/2018 02:47 PM, Heiko Schocher wrote:
on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based
On Wed, Aug 29, 2018 at 04:54:30PM +0200, Richard Weinberger wrote:
> Am Mittwoch, 29. August 2018, 16:38:34 CEST schrieb Sascha Hauer:
> > On Mon, Aug 27, 2018 at 10:48:26PM +0200, Richard Weinberger wrote:
> > > > release_head(c, BASEHD);
> > > > kfree(dent);
> > > > +
On Wed, Aug 29, 2018 at 04:54:30PM +0200, Richard Weinberger wrote:
> Am Mittwoch, 29. August 2018, 16:38:34 CEST schrieb Sascha Hauer:
> > On Mon, Aug 27, 2018 at 10:48:26PM +0200, Richard Weinberger wrote:
> > > > release_head(c, BASEHD);
> > > > kfree(dent);
> > > > +
On Wed, 29 Aug 2018, Nadav Amit wrote:
> at 8:47 AM, Andy Lutomirski wrote:
>
> > In NMI context, we might be in the middle of context switching or in
> > the middle of switch_mm_irqs_off(). In either case, CR3 might not
> > match current->mm, which could cause copy_from_user_nmi() and
> >
On Wed, 29 Aug 2018, Nadav Amit wrote:
> at 8:47 AM, Andy Lutomirski wrote:
>
> > In NMI context, we might be in the middle of context switching or in
> > the middle of switch_mm_irqs_off(). In either case, CR3 might not
> > match current->mm, which could cause copy_from_user_nmi() and
> >
On 24 August 2018 at 12:38, Lorenzo Pieralisi wrote:
> On Fri, Aug 24, 2018 at 11:26:19AM +0200, Ulf Hansson wrote:
>
> [...]
>
>> > That's a good question and it maybe gives a path towards a solution.
>> >
>> > AFAICS the genPD governor only selects the idle state parameter that
>> > determines
On 24 August 2018 at 12:38, Lorenzo Pieralisi wrote:
> On Fri, Aug 24, 2018 at 11:26:19AM +0200, Ulf Hansson wrote:
>
> [...]
>
>> > That's a good question and it maybe gives a path towards a solution.
>> >
>> > AFAICS the genPD governor only selects the idle state parameter that
>> > determines
Hi,
On 08/30/2018 02:47 PM, Heiko Schocher wrote:
> on the imx6ull the input_val for uart5 rx function
> of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
> is 7 and not 5 as on the imx6ul. With this
> patch, console on an imx6ull based board works
> with uart5.
>
> Signed-off-by: Heiko Schocher
Hi,
On 08/30/2018 02:47 PM, Heiko Schocher wrote:
> on the imx6ull the input_val for uart5 rx function
> of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
> is 7 and not 5 as on the imx6ul. With this
> patch, console on an imx6ull based board works
> with uart5.
>
> Signed-off-by: Heiko Schocher
Hi,
Got this on a recent kernel (pretty sure it was
2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops
itself doesn't tell me the exact version):
[ cut here ]
trying to isolate tail page
WARNING: CPU: 2 PID: 19156 at mm/vmscan.c:1756
Hi,
Got this on a recent kernel (pretty sure it was
2ad0d52699700a91660a406a4046017a2d7f246a but annoyingly the oops
itself doesn't tell me the exact version):
[ cut here ]
trying to isolate tail page
WARNING: CPU: 2 PID: 19156 at mm/vmscan.c:1756
On 30-08-18, 10:11, Andrea Merello wrote:
> On Wed, Aug 29, 2018 at 10:12 AM Andrea Merello
> wrote:
> >
> > On Mon, Aug 27, 2018 at 7:30 AM Vinod wrote:
> > >
> > > On 02-08-18, 16:10, Andrea Merello wrote:
> > >
> > > s/cylic/cyclic in patch title
> >
> > OK
> >
> > > > Whenever a single or
On 30-08-18, 10:11, Andrea Merello wrote:
> On Wed, Aug 29, 2018 at 10:12 AM Andrea Merello
> wrote:
> >
> > On Mon, Aug 27, 2018 at 7:30 AM Vinod wrote:
> > >
> > > On 02-08-18, 16:10, Andrea Merello wrote:
> > >
> > > s/cylic/cyclic in patch title
> >
> > OK
> >
> > > > Whenever a single or
Hey Peter,
On 30-08-18, 11:57, Peter Ujfalusi wrote:
> On 2018-08-29 19:22, Vinod wrote:
> + * 2. use dmaengine_desc_attach_metadata() to attach the buffer to the
> + * descriptor
> + * 3. submit the transfer
> + * - DMA_DEV_TO_MEM:
> + * 1. prepare the
Hey Peter,
On 30-08-18, 11:57, Peter Ujfalusi wrote:
> On 2018-08-29 19:22, Vinod wrote:
> + * 2. use dmaengine_desc_attach_metadata() to attach the buffer to the
> + * descriptor
> + * 3. submit the transfer
> + * - DMA_DEV_TO_MEM:
> + * 1. prepare the
On Thu, 30 Aug 2018, Feng Tang wrote:
> On Thu, Aug 30, 2018 at 03:05:31PM +0200, Thomas Gleixner wrote:
> > > Those [_text, __bss_stop] is not able to be used by alloc_bootmem(). And I
> > > only got this patch, and really appreciate any good suggestions.
> >
> > And why do you want to use
On Thu, 30 Aug 2018, Feng Tang wrote:
> On Thu, Aug 30, 2018 at 03:05:31PM +0200, Thomas Gleixner wrote:
> > > Those [_text, __bss_stop] is not able to be used by alloc_bootmem(). And I
> > > only got this patch, and really appreciate any good suggestions.
> >
> > And why do you want to use
Put the pointer to struct regmap_irq_chip_data into the parent
mfd structure so that the child irqchip driver does not need
a trivial private structure to store only this pointer. As
the irqchip child driver already has a pointer to the parent
struct madera it can use that to store the pointer.
Put the pointer to struct regmap_irq_chip_data into the parent
mfd structure so that the child irqchip driver does not need
a trivial private structure to store only this pointer. As
the irqchip child driver already has a pointer to the parent
struct madera it can use that to store the pointer.
The Cirrus Logic Madera codecs (Cirrus Logic CS47L35/85/90/91 and WM1840)
are highly complex devices containing up to 7 programmable DSPs and many
other internal sources of interrupts plus a number of GPIOs that can be
used as interrupt inputs. The large number (>150) of internal interrupt
sources
On Wed, Aug 29, 2018 at 04:43:30PM -0700, Andrew Morton wrote:
> On Tue, 28 Aug 2018 22:35:02 +0300 Alexey Dobriyan
> wrote:
>
> > > Are we really in a super hot path to justify all that?
> >
> > /proc is very slow, try profiling just about anything involving /proc.
>
> So how much does this
The Cirrus Logic Madera codecs (Cirrus Logic CS47L35/85/90/91 and WM1840)
are highly complex devices containing up to 7 programmable DSPs and many
other internal sources of interrupts plus a number of GPIOs that can be
used as interrupt inputs. The large number (>150) of internal interrupt
sources
On Wed, Aug 29, 2018 at 04:43:30PM -0700, Andrew Morton wrote:
> On Tue, 28 Aug 2018 22:35:02 +0300 Alexey Dobriyan
> wrote:
>
> > > Are we really in a super hot path to justify all that?
> >
> > /proc is very slow, try profiling just about anything involving /proc.
>
> So how much does this
Hi Thomas,
On Thu, Aug 30, 2018 at 03:05:31PM +0200, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Feng Tang wrote:
> > On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> > > On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > > > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > > >
Hi Thomas,
On Thu, Aug 30, 2018 at 03:05:31PM +0200, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Feng Tang wrote:
> > On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> > > On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > > > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > > >
On Wed, Aug 29, 2018 at 09:50:50AM +, David Laight wrote:
> From: Alexey Dobriyan
> > Sent: 28 August 2018 00:15
> > ---
> > fs/proc/self.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/proc/self.c b/fs/proc/self.c
> > index
On Wed, Aug 29, 2018 at 09:50:50AM +, David Laight wrote:
> From: Alexey Dobriyan
> > Sent: 28 August 2018 00:15
> > ---
> > fs/proc/self.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/proc/self.c b/fs/proc/self.c
> > index
It was discovered that a constant stream of readers with occassional
writers pounding on a rwsem may cause many of the readers to enter the
slowpath unnecessarily thus increasing latency and lowering performance.
In the current code, a reader entering the slowpath critical section
will
It was discovered that a constant stream of readers with occassional
writers pounding on a rwsem may cause many of the readers to enter the
slowpath unnecessarily thus increasing latency and lowering performance.
In the current code, a reader entering the slowpath critical section
will
On Thu, 30 Aug 2018, Feng Tang wrote:
> On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> > On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > > > On Thu, Aug 30, 2018 at
On Thu, 30 Aug 2018, Feng Tang wrote:
> On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> > On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > > > On Thu, Aug 30, 2018 at
LWN wrote:
> Marking places where unsigned overflow is expected is needed; it would be
> nice to get those annotations put into the kernel, Cook said.
Let's discuss the most important part -- naming :^)
In my opinion, signed universe should _not_ get anything before specific
examples are
LWN wrote:
> Marking places where unsigned overflow is expected is needed; it would be
> nice to get those annotations put into the kernel, Cook said.
Let's discuss the most important part -- naming :^)
In my opinion, signed universe should _not_ get anything before specific
examples are
On Thu, Aug 30, 2018 at 12:55:30PM +0200, Siegfried Metz wrote:
> Dear kernel developers,
>
> since mainline kernel 4.18 (up to the latest mainline kernel 4.18.5)
> Intel Core 2 Duo processors are affected by boot stalling early in the
> boot process. As it is so early there is no dmesg output
On Thu, Aug 30, 2018 at 12:55:30PM +0200, Siegfried Metz wrote:
> Dear kernel developers,
>
> since mainline kernel 4.18 (up to the latest mainline kernel 4.18.5)
> Intel Core 2 Duo processors are affected by boot stalling early in the
> boot process. As it is so early there is no dmesg output
On Mon, 27 Aug 2018, Gu Zhimin wrote:
> diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> new file mode 100644
> index 000..6f91f7b
> --- /dev/null
> +++ b/arch/x86/power/hibernate.c
> @@ -0,0 +1,255 @@
> +/*
> + * Hibernation support for x86
> + *
> + * Distribute under
On Mon, 27 Aug 2018, Gu Zhimin wrote:
> diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> new file mode 100644
> index 000..6f91f7b
> --- /dev/null
> +++ b/arch/x86/power/hibernate.c
> @@ -0,0 +1,255 @@
> +/*
> + * Hibernation support for x86
> + *
> + * Distribute under
On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > > The root
On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > > The root
On Wed, Aug 29, 2018 at 02:10:47PM -0700, Paul E. McKenney wrote:
> From: Alan Stern
>
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by locking. In other words, given
> the following code:
>
> WRITE_ONCE(x, 1);
>
On Wed, Aug 29, 2018 at 02:10:47PM -0700, Paul E. McKenney wrote:
> From: Alan Stern
>
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by locking. In other words, given
> the following code:
>
> WRITE_ONCE(x, 1);
>
On 30-Aug 11:47, Quentin Perret wrote:
> On Thursday 30 Aug 2018 at 11:00:20 (+0100), Patrick Bellasi wrote:
> > Dunno... but, in any case, probably we don't care about using EAS until
> > the boot complete, isn't it?
>
> So, as of now, EAS will typically start soon after CPUFreq. I don't see a
>
On 30-Aug 11:47, Quentin Perret wrote:
> On Thursday 30 Aug 2018 at 11:00:20 (+0100), Patrick Bellasi wrote:
> > Dunno... but, in any case, probably we don't care about using EAS until
> > the boot complete, isn't it?
>
> So, as of now, EAS will typically start soon after CPUFreq. I don't see a
>
On Thu, 2018-08-30 at 11:28 +0300, Dan Carpenter wrote:
> On Wed, Aug 29, 2018 at 06:03:26PM -0400, Nicholas Krause wrote:
> > Fix a checkpatch warning for the file, fwserial.c that warns about
> > alignment between parentheses and the line belows code not being
> > properly aligned with each
On Thu, 2018-08-30 at 11:28 +0300, Dan Carpenter wrote:
> On Wed, Aug 29, 2018 at 06:03:26PM -0400, Nicholas Krause wrote:
> > Fix a checkpatch warning for the file, fwserial.c that warns about
> > alignment between parentheses and the line belows code not being
> > properly aligned with each
On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Michal Hocko wrote:
> > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > The root cause is that when CONFIG_NO_BOOTMEM=y, before
> > > >
On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Michal Hocko wrote:
> > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > The root cause is that when CONFIG_NO_BOOTMEM=y, before
> > > >
on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based board works
with uart5.
Signed-off-by: Heiko Schocher
---
arch/arm/boot/dts/imx6ull-pinfunc.h | 1 +
1 file changed, 1
on the imx6ull the input_val for uart5 rx function
of pin MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX
is 7 and not 5 as on the imx6ul. With this
patch, console on an imx6ull based board works
with uart5.
Signed-off-by: Heiko Schocher
---
arch/arm/boot/dts/imx6ull-pinfunc.h | 1 +
1 file changed, 1
On Mon, 27 Aug 2018, Gu Zhimin wrote:
>
> Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
> This issue should also exist on 64bits systems, if there are reserved
> regions above 4GB.
Should? Can we please have facts and not some half baken assumptions?
On 64bit max_low_pfn
On Mon, 27 Aug 2018, Gu Zhimin wrote:
>
> Fix this problem by changing pfn limit from max_low_pfn to max_pfn.
> This issue should also exist on 64bits systems, if there are reserved
> regions above 4GB.
Should? Can we please have facts and not some half baken assumptions?
On 64bit max_low_pfn
From: Colin Ian King
Variable max_keys is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
variable 'max_keys' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King
---
drivers/input/keyboard/tca8418_keypad.c | 3 +--
1
From: Colin Ian King
Variable max_keys is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
variable 'max_keys' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King
---
drivers/input/keyboard/tca8418_keypad.c | 3 +--
1
On Thu 30-08-18 14:09:26, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 01:12:07PM +0200, Michal Hocko wrote:
> > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > We hit a kernel panic when enabling earlycon for a platform,
On Thu 30-08-18 14:09:26, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 01:12:07PM +0200, Michal Hocko wrote:
> > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > We hit a kernel panic when enabling earlycon for a platform,
Hi Peter,
On Thu, Aug 30, 2018 at 12:44:02PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > We hit a kernel panic when enabling earlycon for a platform, the
> > call trace is:
> >
> > panic+0xd2/0x220
> > __alloc_bootmem+0x31/0x34
> >
Hi Peter,
On Thu, Aug 30, 2018 at 12:44:02PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > We hit a kernel panic when enabling earlycon for a platform, the
> > call trace is:
> >
> > panic+0xd2/0x220
> > __alloc_bootmem+0x31/0x34
> >
ACPI may contain an SPCR table that defines a default system console.
On ARM if the table is present then the SPCR console is enabled by default.
On x86 the SPCR console is used if 'earlycon' (no parameters) is
specified as a kernel parameter and is used only as the early console.
To use the SPCR
ACPI may contain an SPCR table that defines a default system console.
On ARM if the table is present then the SPCR console is enabled by default.
On x86 the SPCR console is used if 'earlycon' (no parameters) is
specified as a kernel parameter and is used only as the early console.
To use the SPCR
On Wed, Aug 29, 2018 at 08:42:49PM +0800, Pu Wen wrote:
> Add x86 architecture support for new processor Hygon Dhyana Family 18h.
> Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the
> AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In
> this way we can
On Wed, Aug 29, 2018 at 08:42:49PM +0800, Pu Wen wrote:
> Add x86 architecture support for new processor Hygon Dhyana Family 18h.
> Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the
> AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In
> this way we can
Commit-ID: 3c76014d27e97bd641202007744fb37c18743adf
Gitweb: https://git.kernel.org/tip/3c76014d27e97bd641202007744fb37c18743adf
Author: Ben Hutchings
AuthorDate: Wed, 29 Aug 2018 20:43:17 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 30 Aug 2018 14:28:19 +0200
x86: Allow
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on vacation for two
Commit-ID: 3c76014d27e97bd641202007744fb37c18743adf
Gitweb: https://git.kernel.org/tip/3c76014d27e97bd641202007744fb37c18743adf
Author: Ben Hutchings
AuthorDate: Wed, 29 Aug 2018 20:43:17 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 30 Aug 2018 14:28:19 +0200
x86: Allow
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on vacation for two
Thanks Bjorn for posting the patch.
On 8/28/2018 10:42 AM, Bjorn Andersson wrote:
The Hexagon v5 ADSP driver is used for more than only the ADSP and
there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
qcom_q6v5_pas in order to better suite this.
Cc: Rohit kumar
Thanks Bjorn for posting the patch.
On 8/28/2018 10:42 AM, Bjorn Andersson wrote:
The Hexagon v5 ADSP driver is used for more than only the ADSP and
there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
qcom_q6v5_pas in order to better suite this.
Cc: Rohit kumar
Hi Linus,
Here's a PR with a couple of MMC fixes intended for v4.19-rc2. Details about the
highlights are as usual found in the signed tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 778a33959a8ad4cb1ea2f4c5119f9e1e8b9f9d9b:
Merge tag
Hi Linus,
Here's a PR with a couple of MMC fixes intended for v4.19-rc2. Details about the
highlights are as usual found in the signed tag.
Please pull this in!
Kind regards
Ulf Hansson
The following changes since commit 778a33959a8ad4cb1ea2f4c5119f9e1e8b9f9d9b:
Merge tag
On 08/30/2018 04:30 AM, Joerg Roedel wrote:
On Thu, Aug 30, 2018 at 03:11:26AM -0700, Guenter Roeck wrote:
OVMF image:
https://github.com/groeck/linux-build-test/blob/master/rootfs/firmware/OVMF-pure-efi-32.fd
Thanks, with this image I can reproduce the issue. Investigating now...
On 08/30/2018 04:30 AM, Joerg Roedel wrote:
On Thu, Aug 30, 2018 at 03:11:26AM -0700, Guenter Roeck wrote:
OVMF image:
https://github.com/groeck/linux-build-test/blob/master/rootfs/firmware/OVMF-pure-efi-32.fd
Thanks, with this image I can reproduce the issue. Investigating now...
Update the provider and client documentation with details about the
metadata support.
Signed-off-by: Peter Ujfalusi
---
Documentation/driver-api/dmaengine/client.rst | 70 +++
.../driver-api/dmaengine/provider.rst | 46
2 files changed, 116 insertions(+)
The metadata is best described as side band data or parameters traveling
alongside the data DMAd by the DMA engine. It is data
which is understood by the peripheral and the peripheral driver only, the
DMA engine see it only as data block and it is not interpreting it in any
way.
The metadata can
Update the provider and client documentation with details about the
metadata support.
Signed-off-by: Peter Ujfalusi
---
Documentation/driver-api/dmaengine/client.rst | 70 +++
.../driver-api/dmaengine/provider.rst | 46
2 files changed, 116 insertions(+)
The metadata is best described as side band data or parameters traveling
alongside the data DMAd by the DMA engine. It is data
which is understood by the peripheral and the peripheral driver only, the
DMA engine see it only as data block and it is not interpreting it in any
way.
The metadata can
Hi,
Changes since v1:
- Move code from header to dmaengine.c
- Fix spelling
- Use BIT() macro for bit definition
- Update both provider and client documentation
Changes since rfc:
- DESC_METADATA_EMBEDDED renamed to DESC_METADATA_ENGINE
- Use flow is added for both CLIENT and ENGINE metadata
Hi,
Changes since v1:
- Move code from header to dmaengine.c
- Fix spelling
- Use BIT() macro for bit definition
- Update both provider and client documentation
Changes since rfc:
- DESC_METADATA_EMBEDDED renamed to DESC_METADATA_ENGINE
- Use flow is added for both CLIENT and ENGINE metadata
On Tue, Aug 28, 2018 at 05:42:26PM -0700, Venkata Narendra Kumar Gutta wrote:
> From: Channagoud Kadabi
>
> Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
> Errors (DBEs). As of now, this driver supports error reporting for
> Last Level Cache Controller (LLCC) of Tag RAM
On Tue, Aug 28, 2018 at 05:42:26PM -0700, Venkata Narendra Kumar Gutta wrote:
> From: Channagoud Kadabi
>
> Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
> Errors (DBEs). As of now, this driver supports error reporting for
> Last Level Cache Controller (LLCC) of Tag RAM
On Thu, Aug 30, 2018 at 01:12:07PM +0200, Michal Hocko wrote:
> On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > We hit a kernel panic when enabling earlycon for a platform, the
> > > call trace is:
> > >
> > >
On Thu, Aug 30, 2018 at 01:12:07PM +0200, Michal Hocko wrote:
> On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > We hit a kernel panic when enabling earlycon for a platform, the
> > > call trace is:
> > >
> > >
On 28 August 2018 at 23:47, Douglas Gilbert wrote:
> I usually boot my Lenovo X270 with a SD card in its:
> # lspci
> 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI
> Express Card Reader (rev 01)
> ...
>
> In lk 4.19.0-rc1 the boot locks up solid, almost
On 28 August 2018 at 23:47, Douglas Gilbert wrote:
> I usually boot my Lenovo X270 with a SD card in its:
> # lspci
> 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI
> Express Card Reader (rev 01)
> ...
>
> In lk 4.19.0-rc1 the boot locks up solid, almost
k...@linuxonhyperv.com writes:
> From: Stephen Hemminger
>
> For unsupported device types, the vmbus channel ringbuffer is never
> initialized, and therefore reading the sysfs files will return garbage
> or cause a kernel OOPS.
>
> Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
>
>
k...@linuxonhyperv.com writes:
> From: Stephen Hemminger
>
> For unsupported device types, the vmbus channel ringbuffer is never
> initialized, and therefore reading the sysfs files will return garbage
> or cause a kernel OOPS.
>
> Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info")
>
>
On Tue, 28 Aug 2018, Petr Mladek wrote:
> livepatch: Atomic replace feature
>
> The atomic replace allows to create cumulative patches. They
> are useful when you maintain many livepatches and want to remove
> one that is lower on the stack. In addition it is very useful when
> more patches
On Tue, 28 Aug 2018, Petr Mladek wrote:
> livepatch: Atomic replace feature
>
> The atomic replace allows to create cumulative patches. They
> are useful when you maintain many livepatches and want to remove
> one that is lower on the stack. In addition it is very useful when
> more patches
On Thu, 30 Aug 2018, Michal Hocko wrote:
> On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > The root cause is that when CONFIG_NO_BOOTMEM=y, before
> > > e820__memblock_setup() is called there is no memory for bootmem
> > > to
On Thu, 30 Aug 2018, Michal Hocko wrote:
> On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > The root cause is that when CONFIG_NO_BOOTMEM=y, before
> > > e820__memblock_setup() is called there is no memory for bootmem
> > > to
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
arch/x86/kernel/cpu/intel_rdt.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
On Thu, 30 Aug 2018, Richard Fitzgerald wrote:
> On 30/08/18 11:31, Thomas Gleixner wrote:
> > On Tue, 28 Aug 2018, Richard Fitzgerald wrote:
> > > @@ -0,0 +1,244 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Interrupt support for Cirrus Logic Madera codecs
> > > + *
> > > + *
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
arch/x86/kernel/cpu/intel_rdt.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git
On Thu, 30 Aug 2018, Richard Fitzgerald wrote:
> On 30/08/18 11:31, Thomas Gleixner wrote:
> > On Tue, 28 Aug 2018, Richard Fitzgerald wrote:
> > > @@ -0,0 +1,244 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Interrupt support for Cirrus Logic Madera codecs
> > > + *
> > > + *
901 - 1000 of 1378 matches
Mail list logo
