On Fri, 23 Nov 2018 18:41:50 +0800 Ian Kent wrote:
> Al Viro made some suggestions to improve the implementation
> of commit 0633da48f0 "fix autofs_sbi() does not check super
> block type".
>
> The check is unnessesary in all cases except for ioctl usage
> so placing the check in the super
On Fri, 23 Nov 2018 18:41:50 +0800 Ian Kent wrote:
> Al Viro made some suggestions to improve the implementation
> of commit 0633da48f0 "fix autofs_sbi() does not check super
> block type".
>
> The check is unnessesary in all cases except for ioctl usage
> so placing the check in the super
On Fri, Nov 23, 2018 at 04:16:59PM +, Russell King - ARM Linux wrote:
> Hi Peter,
>
> Here's the patch, which should now support IN as well as OUT.
> Completely untested, as mentioned before.
Now compile tested...
drivers/usb/gadget/udc/omap_udc.c | 291
On Fri, Nov 23, 2018 at 04:16:59PM +, Russell King - ARM Linux wrote:
> Hi Peter,
>
> Here's the patch, which should now support IN as well as OUT.
> Completely untested, as mentioned before.
Now compile tested...
drivers/usb/gadget/udc/omap_udc.c | 291
Hi!
> We have a problem with USBPD chargers which under certain conditions
> can result in system overheating if the voltage provided by the USBPD
> port is too high. While the preferred means to control this would be
> through devicetree or ACPI settings, this is not always possible, and
> we
Hi!
> We have a problem with USBPD chargers which under certain conditions
> can result in system overheating if the voltage provided by the USBPD
> port is too high. While the preferred means to control this would be
> through devicetree or ACPI settings, this is not always possible, and
> we
On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> If the kernel provides a system call, libc should provide a C wrapper
> > >>> for it, even if in
On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> If the kernel provides a system call, libc should provide a C wrapper
> > >>> for it, even if in
--
Hello Dear ,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate
--
Hello Dear ,
I came across your contact during my private search
Mrs Aisha Al-Qaddafi is my name, the only daughter of late Libyan
president, I have funds the sum
of $27.5 million USD for investment, I am interested in you for
investment project assistance in your country,
i shall compensate
On Fri, 23 Nov 2018 15:33:21 + Mark Rutland wrote:
> Andrew and Ingo report that the check-atomics.sh script is simply too
> slow to run for every kernel build, and it's impractical to make it
> faster without rewriting it in something other than shell.
>
> Rather than committing the
On Fri, 23 Nov 2018 15:33:21 + Mark Rutland wrote:
> Andrew and Ingo report that the check-atomics.sh script is simply too
> slow to run for every kernel build, and it's impractical to make it
> faster without rewriting it in something other than shell.
>
> Rather than committing the
In commit cb5e39b8038b ("drivers: base: refactor add_memory_section() to
add_memory_block()"), add_memory_block() is introduced, which is only
invoked in memory_dev_init().
When combine these two loops in memory_dev_init() and
add_memory_block(), they looks like this:
for (i = 0; i <
In commit cb5e39b8038b ("drivers: base: refactor add_memory_section() to
add_memory_block()"), add_memory_block() is introduced, which is only
invoked in memory_dev_init().
When combine these two loops in memory_dev_init() and
add_memory_block(), they looks like this:
for (i = 0; i <
On Fri, Nov 23, 2018 at 01:11:38PM -0500, Steven Rostedt wrote:
> On Fri, 23 Nov 2018 12:58:34 -0500
> Steven Rostedt wrote:
>
> > I think the better answer is to move it into trace_functions_graph.c.
>
> I take that back. I think the better answer is to not call that
> function if the profiler
On Fri, Nov 23, 2018 at 01:11:38PM -0500, Steven Rostedt wrote:
> On Fri, 23 Nov 2018 12:58:34 -0500
> Steven Rostedt wrote:
>
> > I think the better answer is to move it into trace_functions_graph.c.
>
> I take that back. I think the better answer is to not call that
> function if the profiler
HI!
> > > > > > > You have general-purpose LED, yet you are treating it as
> > > > > > > "something
> > > > > > > special". That means ugly code (quoted above) and lack of
> > > > > > > flexibility.
> > > > > > >
> > > > > > > For example, if my notebook lacks HDD LED, I can use scrollock
> >
HI!
> > > > > > > You have general-purpose LED, yet you are treating it as
> > > > > > > "something
> > > > > > > special". That means ugly code (quoted above) and lack of
> > > > > > > flexibility.
> > > > > > >
> > > > > > > For example, if my notebook lacks HDD LED, I can use scrollock
> >
On Thu, 22 Nov 2018, Waiman Long wrote:
> On 11/22/2018 11:31 PM, Qian Cai wrote:
> > The current value of the early boot static pool size, 1024 is not big
> > enough for systems with large number of CPUs with timer or/and workqueue
> > objects selected. As the results, systems have 60+ CPUs with
On Thu, 22 Nov 2018, Waiman Long wrote:
> On 11/22/2018 11:31 PM, Qian Cai wrote:
> > The current value of the early boot static pool size, 1024 is not big
> > enough for systems with large number of CPUs with timer or/and workqueue
> > objects selected. As the results, systems have 60+ CPUs with
From Desk of James Brown
Accountant officer Wema bank Of Nigeria
Hello My Dear ,
My name is James Brown I have decided to seek a confidential
co-operation with you in the execution of the deal described here-under
for our both mutual benefit and I hope you will keep it a top secret
because
From Desk of James Brown
Accountant officer Wema bank Of Nigeria
Hello My Dear ,
My name is James Brown I have decided to seek a confidential
co-operation with you in the execution of the deal described here-under
for our both mutual benefit and I hope you will keep it a top secret
because
On Fri, Nov 23, 2018 at 11:21 AM Dave Hansen wrote:
>
> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
> > Are we willing to go in the direction for inclusion of a new system
> > call, subset of it appears on sysfs etc ? My primary concern is not
> > how the attribute information appears on the
On Fri, Nov 23, 2018 at 11:21 AM Dave Hansen wrote:
>
> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
> > Are we willing to go in the direction for inclusion of a new system
> > call, subset of it appears on sysfs etc ? My primary concern is not
> > how the attribute information appears on the
- On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >>
- On Nov 23, 2018, at 1:35 PM, Rich Felker dal...@libc.org wrote:
> On Fri, Nov 23, 2018 at 12:52:21PM -0500, Mathieu Desnoyers wrote:
>> - On Nov 23, 2018, at 12:30 PM, Rich Felker dal...@libc.org wrote:
>>
>> > On Fri, Nov 23, 2018 at 12:05:20PM -0500, Mathieu Desnoyers wrote:
>> >>
On Fri, Nov 23, 2018 at 01:03:25PM -0800, Guenter Roeck wrote:
> It is a cut off screen log. x86 boots change xterm configuration from
> wrap to non-wrap, and I did a cut-and-paste instead of copying the log
> to a file. Sorry for that.
No worries.
It was a head-scratcher though because look
On Fri, Nov 23, 2018 at 01:03:25PM -0800, Guenter Roeck wrote:
> It is a cut off screen log. x86 boots change xterm configuration from
> wrap to non-wrap, and I did a cut-and-paste instead of copying the log
> to a file. Sorry for that.
No worries.
It was a head-scratcher though because look
On 11/23/18 12:44 PM, Borislav Petkov wrote:
On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:
[0.762832] EIP: read_tsc+0x4/0x10
[0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90 90 90
90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57
On 11/23/18 12:44 PM, Borislav Petkov wrote:
On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:
[0.762832] EIP: read_tsc+0x4/0x10
[0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90 90 90
90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57
On Fri, Nov 23, 2018 at 11:14:25PM +0800, Wei Hu (Xavier) wrote:
> This patch modifies the name of hns RoCE device's name in order
> to ensure that the name is consistent before and after reset.
>
> Signed-off-by: Wei Hu (Xavier)
> drivers/infiniband/hw/hns/hns_roce_device.h | 1 +
>
On Fri, Nov 23, 2018 at 11:14:25PM +0800, Wei Hu (Xavier) wrote:
> This patch modifies the name of hns RoCE device's name in order
> to ensure that the name is consistent before and after reset.
>
> Signed-off-by: Wei Hu (Xavier)
> drivers/infiniband/hw/hns/hns_roce_device.h | 1 +
>
On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:
> [0.762832] EIP: read_tsc+0x4/0x10
> [0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90
> 90 90 90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57 <0f> ae
> f0b
Where does that 'b' in f0b
On Fri, Nov 23, 2018 at 12:03:07PM -0800, Guenter Roeck wrote:
> [0.762832] EIP: read_tsc+0x4/0x10
> [0.762832] Code: 00 01 00 eb 89 90 55 89 e5 5d c3 90 90 90 90 90 90 90 90
> 90 90 90 55 a1 44 5a 8b c5 89 e5 5d c3 8d b6 00 00 00 00 55 89 e5 57 <0f> ae
> f0b
Where does that 'b' in f0b
On Fri, 23 Nov 2018, h...@zytor.com wrote:
> On November 23, 2018 12:03:07 PM PST, Guenter Roeck
> wrote:
> ># first bad commit: [2e94061096c5c3aa6c3fe3ec2bec176c1f9c1b07] x86/TSC:
> >Use RDTSCP
>
> Right, because that cpu predates RDTSCP, so it needs to use a fallback.
Well, that's not the
On Fri, 23 Nov 2018, h...@zytor.com wrote:
> On November 23, 2018 12:03:07 PM PST, Guenter Roeck
> wrote:
> ># first bad commit: [2e94061096c5c3aa6c3fe3ec2bec176c1f9c1b07] x86/TSC:
> >Use RDTSCP
>
> Right, because that cpu predates RDTSCP, so it needs to use a fallback.
Well, that's not the
On Fri, Nov 23, 2018 at 11:14:22PM +0800, Wei Hu (Xavier) wrote:
> Hi, Doug and Janson
>
> This series mainly include updates for reset process of roce device
> in hip08.
> One patch adds support for reset and loading or unloading driver occur
> simultaneously to ensure work normally, one stops
On Fri, Nov 23, 2018 at 11:14:22PM +0800, Wei Hu (Xavier) wrote:
> Hi, Doug and Janson
>
> This series mainly include updates for reset process of roce device
> in hip08.
> One patch adds support for reset and loading or unloading driver occur
> simultaneously to ensure work normally, one stops
Cleanup remaining comparsions to true.
if (x == true) -> if (x)
if (x != true) -> if (!x)
if (!x == true) -> if (!x)
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 4 +--
drivers/staging/rtl8188eu/core/rtw_cmd.c | 10 +++---
Use __func__ instead of hardcoded function names.
Reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 48 +--
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
Cleanup remaining comparsions to true.
if (x == true) -> if (x)
if (x != true) -> if (!x)
if (!x == true) -> if (!x)
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 4 +--
drivers/staging/rtl8188eu/core/rtw_cmd.c | 10 +++---
Use __func__ instead of hardcoded function names.
Reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 48 +--
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
The function rtw_android_set_block() just returns zero. The only user
is the function rtw_android_priv_cmd(). The variable bytes_written is
initialized to zero and not changed before the use of
rtw_android_set_block(). Remove rtw_android_set_block() and it's only
use.
Signed-off-by: Michael
The function rtw_android_set_block() just returns zero. The only user
is the function rtw_android_priv_cmd(). The variable bytes_written is
initialized to zero and not changed before the use of
rtw_android_set_block(). Remove rtw_android_set_block() and it's only
use.
Signed-off-by: Michael
Correct indentation to clear a checkpatch warning.
WARNING: suspect code indent for conditional statements (8, 24)
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Cleanup lines over 80 characters by replacing tabs with spaces
or adding appropriate line breaks.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
Correct indentation to clear a checkpatch warning.
WARNING: suspect code indent for conditional statements (8, 24)
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Cleanup lines over 80 characters by replacing tabs with spaces
or adding appropriate line breaks.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
Remove return from a void function to clear a checkpatch warning.
WARNING: void function return statements are not generally useful
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Replace tabs with spaces, remove spaces, remove blank lines
and break lines appropriatly in declarations.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 130 +++---
1 file changed, 64 insertions(+), 66 deletions(-)
diff --git
Refactor if else statement to clear checkpatch warnings.
WARNING: else is not generally useful after a break or return
WARNING: line over 80 characters
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
Remove return from a void function to clear a checkpatch warning.
WARNING: void function return statements are not generally useful
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 --
1 file changed, 2 deletions(-)
diff --git
Replace tabs with spaces, remove spaces, remove blank lines
and break lines appropriatly in declarations.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 130 +++---
1 file changed, 64 insertions(+), 66 deletions(-)
diff --git
Refactor if else statement to clear checkpatch warnings.
WARNING: else is not generally useful after a break or return
WARNING: line over 80 characters
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
Remove unnecessary parentheses reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 120 --
1 file changed, 63 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
Remove unnecessary parentheses reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 120 --
1 file changed, 63 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
"lfence; rdtsc", X86_FEATURE_LFENCE_RDTSC,
>> + "rdtscp", X86_FEATURE_RDTSCP)
>> +: EAX_EDX_RET(val, low, high)
>> +/* RDTSCP clobbers ECX with MSR_TSC_AUX. */
>>
"lfence; rdtsc", X86_FEATURE_LFENCE_RDTSC,
>> + "rdtscp", X86_FEATURE_RDTSCP)
>> +: EAX_EDX_RET(val, low, high)
>> +/* RDTSCP clobbers ECX with MSR_TSC_AUX. */
>>
On Thu, 22 Nov 2018, Michal Hocko wrote:
>
> If you want some update to the comment in this function or to the
> changelog, I am open of course. Right now I have
> +* Check for a locked page first, as a speculative
> +* reference may adversely influence page
On Thu, 22 Nov 2018, Michal Hocko wrote:
>
> If you want some update to the comment in this function or to the
> changelog, I am open of course. Right now I have
> +* Check for a locked page first, as a speculative
> +* reference may adversely influence page
On 11/22/18 9:49 AM, Roberto Sassu wrote:
> Although rootfs (tmpfs) supports xattrs, they are not set due to the
> limitation of the cpio format. A new format called 'newcx' was proposed to
> overcome this limitation.
I got email about that format the day before you posted this, by the way.
>
On 11/22/18 9:49 AM, Roberto Sassu wrote:
> Although rootfs (tmpfs) supports xattrs, they are not set due to the
> limitation of the cpio format. A new format called 'newcx' was proposed to
> overcome this limitation.
I got email about that format the day before you posted this, by the way.
>
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> >> * Daniel Colascione:
> >>
> >>> If the kernel provides a system call, libc should provide a C wrapper
> >>> for it, even if in the opinion of the libc
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> >> * Daniel Colascione:
> >>
> >>> If the kernel provides a system call, libc should provide a C wrapper
> >>> for it, even if in the opinion of the libc
On Wed, 21 Nov 2018, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:54:42 -0700 Yu Zhao wrote:
>
> > We changed key of swap cache tree from swp_entry_t.val to
> > swp_offset. Need to do so in shmem_replace_page() as well.
>
> What are the user-visible effects of this change?
Sorry, I don't
On Wed, 21 Nov 2018, Andrew Morton wrote:
> On Wed, 21 Nov 2018 14:54:42 -0700 Yu Zhao wrote:
>
> > We changed key of swap cache tree from swp_entry_t.val to
> > swp_offset. Need to do so in shmem_replace_page() as well.
>
> What are the user-visible effects of this change?
Sorry, I don't
quot;ecx");
> +
> + return EAX_EDX_VAL(val, low, high);
> }
>
This patch results in a crash with certain qemu emulations.
[0.756869] hpet0: 3 comparators, 64-bit 100.00 MHz counter
[0.762233] invalid opcode: [#1] PTI
[0.762435] CPU: 0 PID: 1 Comm: swapp
quot;ecx");
> +
> + return EAX_EDX_VAL(val, low, high);
> }
>
This patch results in a crash with certain qemu emulations.
[0.756869] hpet0: 3 comparators, 64-bit 100.00 MHz counter
[0.762233] invalid opcode: [#1] PTI
[0.762435] CPU: 0 PID: 1 Comm: swapp
On Fri, Nov 23, 2018 at 02:26:17PM -0500, Steven Rostedt wrote:
On Fri, 23 Nov 2018 13:34:15 -0500
Sasha Levin wrote:
Does this mean that someone (Steve) will send a backport of this to all
relevant stable trees? Right now it looks like the series will randomly
apply on a mix of trees, which
On Fri, Nov 23, 2018 at 02:26:17PM -0500, Steven Rostedt wrote:
On Fri, 23 Nov 2018 13:34:15 -0500
Sasha Levin wrote:
Does this mean that someone (Steve) will send a backport of this to all
relevant stable trees? Right now it looks like the series will randomly
apply on a mix of trees, which
The Meson8b SoC is using four Cortex-A5 cores. These come with an ARM
global timer.
This adds the Cortex-A5 global timer but keeps it disabled for now. The
timer is clocked by the "PERIPH" clock whose rate can change during
runtime (when changing the frequency of the CPU clock). Unfortunately
the
The public Meson8b (S805) datasheet describes a memory region called "A9
Periph base" which starts at 0xC430 and ends at 0xC430. Add a
simple-bus node and move all peripherals that are part of this memory
region.
This makes the .dts a bit easier to read. No functional changes.
The Meson8 and Meson8m2 SoC are using four ARM Cortex-A9 cores which
come with a "TWD" (Timer-Watchdog) based timer. This adds support for
the ARM TWD Timer on these two SoCs.
Suggested-by: Carlo Caione
[ rebased patch from Carlo, use IRQ_TYPE_EDGE_RISING instead of
IRQ_TYPE_LEVEL_LOW to
The 32-bit Meson SoCs use Cortex-A9 or Cortex-A5 cores. These come
with the ARM TWD ("Timer Watchdog") which contains a timer and a
watchdog as well as the ARM Global Timer.
This enables the corresponding configs for the 32-bit Meson target.
Additionally this adds and enables the ARM TWD timer.
The Meson8 and Meson8m2 SoCs are using four Cortex-A9 cores. These come
with an ARM global timer.
This adds the Cortex-A9 global timer but keeps it disabled for now. The
timer is clocked by the "PERIPH" clock whose rate can change during
runtime (when changing the frequency of the CPU clock).
The 32-bit Meson SoCs use multiple Cortex-A9 (Meson8 and Meson8m2) or
Cortex-A5 (Meson8b) CPU cores. These come with the "ARM global timer"
and "Timer-Watchdog" (aka TWD, which provides both a per-cpu local timer
and watchdog).
Selecting ARM_GLOBAL_TIMER and HAVE_ARM_TWD allows us to add the
The Meson8B SoC is using four ARM Cortex-A5 cores which come with a
"TWD" (Timer-Watchdog) based timer. This adds support for the ARM TWD
Timer on this SoC.
Suggested-by: Carlo Caione
[ rebased patch from Carlo, use IRQ_TYPE_EDGE_RISING instead of
IRQ_TYPE_LEVEL_LOW to prevent "GIC: PPI13 is
The public Meson8b (S805) datasheet describes a memory region called "A9
Periph base" which starts at 0xC430 and ends at 0xC430. Add a
simple-bus node and move all peripherals that are part of this memory
region.
This makes the .dts a bit easier to read. No functional changes.
The Meson8 and Meson8m2 SoC are using four ARM Cortex-A9 cores which
come with a "TWD" (Timer-Watchdog) based timer. This adds support for
the ARM TWD Timer on these two SoCs.
Suggested-by: Carlo Caione
[ rebased patch from Carlo, use IRQ_TYPE_EDGE_RISING instead of
IRQ_TYPE_LEVEL_LOW to
The 32-bit Meson SoCs use Cortex-A9 or Cortex-A5 cores. These come
with the ARM TWD ("Timer Watchdog") which contains a timer and a
watchdog as well as the ARM Global Timer.
This enables the corresponding configs for the 32-bit Meson target.
Additionally this adds and enables the ARM TWD timer.
The Meson8 and Meson8m2 SoCs are using four Cortex-A9 cores. These come
with an ARM global timer.
This adds the Cortex-A9 global timer but keeps it disabled for now. The
timer is clocked by the "PERIPH" clock whose rate can change during
runtime (when changing the frequency of the CPU clock).
The 32-bit Meson SoCs use multiple Cortex-A9 (Meson8 and Meson8m2) or
Cortex-A5 (Meson8b) CPU cores. These come with the "ARM global timer"
and "Timer-Watchdog" (aka TWD, which provides both a per-cpu local timer
and watchdog).
Selecting ARM_GLOBAL_TIMER and HAVE_ARM_TWD allows us to add the
The Meson8B SoC is using four ARM Cortex-A5 cores which come with a
"TWD" (Timer-Watchdog) based timer. This adds support for the ARM TWD
Timer on this SoC.
Suggested-by: Carlo Caione
[ rebased patch from Carlo, use IRQ_TYPE_EDGE_RISING instead of
IRQ_TYPE_LEVEL_LOW to prevent "GIC: PPI13 is
The Meson8b SoC is using four Cortex-A5 cores. These come with an ARM
global timer.
This adds the Cortex-A5 global timer but keeps it disabled for now. The
timer is clocked by the "PERIPH" clock whose rate can change during
runtime (when changing the frequency of the CPU clock). Unfortunately
the
On Fri, Nov 23, 2018 at 3:40 PM Neil Armstrong wrote:
>
> On 22/11/2018 22:40, Martin Blumenstingl wrote:
> > This is the successor to my previous series "meson8b: add the CPU_DIV16
> > clock for the ARM TWD" from [0]. I decided to not send this as v2 of
> > the original series because the PERIPH
On Fri, Nov 23, 2018 at 3:40 PM Neil Armstrong wrote:
>
> On 22/11/2018 22:40, Martin Blumenstingl wrote:
> > This is the successor to my previous series "meson8b: add the CPU_DIV16
> > clock for the ARM TWD" from [0]. I decided to not send this as v2 of
> > the original series because the PERIPH
On Fri, Nov 23, 2018 at 7:15 AM Daniel Lezcano
wrote:
>
> On 22/11/2018 23:12, Martin Blumenstingl wrote:
> > Hi Daniel,
> >
> > On Sun, Nov 18, 2018 at 2:27 AM Daniel Lezcano
> > wrote:
> >>
> >> On 15/11/2018 23:46, Martin Blumenstingl wrote:
> >>> While trying to add support for the ARM TWD
On Fri, Nov 23, 2018 at 7:15 AM Daniel Lezcano
wrote:
>
> On 22/11/2018 23:12, Martin Blumenstingl wrote:
> > Hi Daniel,
> >
> > On Sun, Nov 18, 2018 at 2:27 AM Daniel Lezcano
> > wrote:
> >>
> >> On 15/11/2018 23:46, Martin Blumenstingl wrote:
> >>> While trying to add support for the ARM TWD
On Fri, 2018-11-23 at 11:03 -0800, Casey Schaufler wrote:
> On 11/22/2018 7:49 AM, Roberto Sassu wrote:
> > Although rootfs (tmpfs) supports xattrs, they are not set due to the
> > limitation of the cpio format. A new format called 'newcx' was proposed to
> > overcome this limitation.
> >
> >
On Fri, 2018-11-23 at 11:03 -0800, Casey Schaufler wrote:
> On 11/22/2018 7:49 AM, Roberto Sassu wrote:
> > Although rootfs (tmpfs) supports xattrs, they are not set due to the
> > limitation of the cpio format. A new format called 'newcx' was proposed to
> > overcome this limitation.
> >
> >
The pull request you sent on Fri, 23 Nov 2018 19:49:19 +0100:
> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7c98a42618271210c60b79128b220107d35938d9
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Fri, 23 Nov 2018 19:49:19 +0100:
> https://github.com/ceph/ceph-client.git tags/ceph-for-4.20-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7c98a42618271210c60b79128b220107d35938d9
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 23 Nov 2018 13:34:15 -0500
Sasha Levin wrote:
> Does this mean that someone (Steve) will send a backport of this to all
> relevant stable trees? Right now it looks like the series will randomly
> apply on a mix of trees, which can't be good.
Nope. I stated that in my 0 patch.
-- Steve
On Fri, 23 Nov 2018 13:34:15 -0500
Sasha Levin wrote:
> Does this mean that someone (Steve) will send a backport of this to all
> relevant stable trees? Right now it looks like the series will randomly
> apply on a mix of trees, which can't be good.
Nope. I stated that in my 0 patch.
-- Steve
On Thu, 22 Nov 2018 19:13:38 -0800
Joel Fernandes wrote:
> On Wed, Nov 21, 2018 at 08:27:17PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)"
> >
> > Move the function function_graph_get_addr() to fgraph.c, as the management
> > of the curr_ret_stack is going to change, and
On Thu, 22 Nov 2018 19:13:38 -0800
Joel Fernandes wrote:
> On Wed, Nov 21, 2018 at 08:27:17PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)"
> >
> > Move the function function_graph_get_addr() to fgraph.c, as the management
> > of the curr_ret_stack is going to change, and
On 11/22/18 10:42 PM, Anshuman Khandual wrote:
> Are we willing to go in the direction for inclusion of a new system
> call, subset of it appears on sysfs etc ? My primary concern is not
> how the attribute information appears on the sysfs but lack of it's
> completeness.
A new system call makes
On 11/22/18 10:42 PM, Anshuman Khandual wrote:
> Are we willing to go in the direction for inclusion of a new system
> call, subset of it appears on sysfs etc ? My primary concern is not
> how the attribute information appears on the sysfs but lack of it's
> completeness.
A new system call makes
> On Nov 23, 2018, at 11:44 AM, Linus Torvalds
> wrote:
>
>> On Fri, Nov 23, 2018 at 10:39 AM Andy Lutomirski wrote:
>>
>> What is memcpy_to_io even supposed to do? I’m guessing it’s defined as
>> something like “copy this data to IO space using at most long-sized writes,
>> all
> On Nov 23, 2018, at 11:44 AM, Linus Torvalds
> wrote:
>
>> On Fri, Nov 23, 2018 at 10:39 AM Andy Lutomirski wrote:
>>
>> What is memcpy_to_io even supposed to do? I’m guessing it’s defined as
>> something like “copy this data to IO space using at most long-sized writes,
>> all
101 - 200 of 840 matches
Mail list logo
