On Fri, Jan 11, 2019 at 02:35:25PM -0700, shuah wrote:
> On 1/11/19 7:14 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.2 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with
On Fri, Jan 11, 2019 at 10:02:57AM -0800, Nick Desaulniers wrote:
> On Fri, Jan 11, 2019 at 6:34 AM Greg Kroah-Hartman
> wrote:
> >
> > 4.14-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Ard Biesheuvel
> >
> > commit
On Fri, 11 Jan 2019 at 19:46, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.4.170 release.
> There are 88 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 Fri, 11 Jan 2019 at 19:58, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.150 release.
> There are 63 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 Fri, Jan 11, 2019 at 03:10:04PM -0500, Nicolas Pitre wrote:
> On Fri, 11 Jan 2019, Greg Kroah-Hartman wrote:
>
> > On Fri, Jan 11, 2019 at 01:33:09PM -0500, Nicolas Pitre wrote:
> > > I use Linux with the help of a braille display and the brltty daemon. It
> > > turns out that the latest
Dne sobota, 12. januar 2019 ob 02:56:11 CET je Chen-Yu Tsai napisal(a):
> On Sat, Jan 12, 2019 at 1:30 AM Jernej Skrabec
wrote:
> > A64 IR is compatible with A13, so add A64 compatible with A13 as a
> > fallback.
>
> We ask people to add the SoC-specific compatible as a contigency,
> in case
From: Guo Ren
max_low_pfn should be pfn_size not byte_size.
Signed-off-by: Guo Ren
Signed-off-by: Mao Han
Cc: Palmer Dabbelt
Cc: Albert Ou
---
arch/riscv/kernel/setup.c | 2 +-
arch/riscv/mm/init.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
On Fri, 11 Jan 2019 at 20:01, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.14.93 release.
> There are 105 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 Fri, 11 Jan 2019 at 20:06, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.15 release.
> There are 148 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 Fri, 11 Jan 2019 at 20:13, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.20.2 release.
> There are 65 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 Sat, Jan 12, 2019 at 3:47 AM William Breathitt Gray
wrote:
>
> This macro iterates for each 8-bit group of bits (clump) with set bits,
> within a bitmap memory region. For each iteration, "start" is set to the
> bit offset of the found clump, while the respective clump value is
> stored to the
Commit-ID: 927185c124d62a9a4d35878d7f6d432a166b74e3
Gitweb: https://git.kernel.org/tip/927185c124d62a9a4d35878d7f6d432a166b74e3
Author: George Rimar
AuthorDate: Fri, 11 Jan 2019 12:10:12 -0800
Committer: Borislav Petkov
CommitDate: Sat, 12 Jan 2019 00:11:39 +0100
x86/build: Specify
* Linus Torvalds wrote:
> On Fri, Jan 11, 2019 at 6:22 AM Ard Biesheuvel
> wrote:
> >
> > I was hoping we could merge this patch (so we can backport it), but
> > resolve the conflict by dropping the kmemleak_ignore() again [..]
>
> Well, we'd drop the new #include line also, since it would
* Linus Torvalds wrote:
> On Thu, Jan 10, 2019 at 11:46 PM Ingo Molnar wrote:
> >
> > A single fix that adds an annotation to resolve a kmemleak false
> > positive.
>
> This one is apparently obviated by commit 80424b02d42b ("efi: Reduce
> the amount of memblock reservations for persistent
HI Peter, Oleg,
as per flag and state this seems to be possible only from below code:
XXX: 0 1 0x40844c
PF_NOFREEZE
PF_RANDOMIZE
PF_SIGNALED
PF_FORKNOEXEC
PF_EXITING
PF_EXITPIDONE
above state shows do_exit runs properely and if somehow after parked
stated , TASK_WAKEKILL got set and
* Lukas Bulwahn wrote:
> The PREEMPTIBLE KERNEL section entry seems quite outdated:
>
> Robert Love is not actively maintaining the file anymore, nor a recorded
> contributor to the files in the PREEMPTIBLE KERNEL section for the last
> few years.
>
> The mailing list
Since this is going to be used on more SoCs than just i.MX8MQ, make
the dependency here more generic by using ARCH_MXC instead.
Also remove the SOC_IMX7D since it is also included by the ARCH_MXC.
Signed-off-by: Abel Vesa
Reviewed-by: Dong Aisheng
---
Changes since v2:
* fixed the commit
On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> Could you please define interesting frame on top a bit more? Usually
> the topmost return address is in LR
There is no reliable way (other than DWARF unwind info) to find out where
the value of LR at function entry currently lives
In the linux kernel MAINTAINERS file, largely
"xen-de...@lists.xenproject.org (moderated for non-subscribers)"
is used to refer to the xen-devel mailing list.
The DRM DRIVERS FOR XEN section entry mentions
xen-de...@lists.xen.org instead, but that is just the same
mailing list as the mailing
On Fri, Jan 11, 2019 at 1:37 AM Guenter Roeck wrote:
> On Wed, Jan 02, 2019 at 09:07:25PM +0530, Firoz Khan wrote:
> > Unified system call table generation script must be run to
> > generate unistd_32.h and syscall_table.h files. This patch
> > will have changes which will invokes the script.
> >
On Fri, Jan 11, 2019 at 03:53:58PM -0500, Sebastien Bourdelin wrote:
> This commit allow the driver to work with device-tree.
>
> Signed-off-by: Sebastien Bourdelin
> ---
I get the following compilation failure:
Below I have `allyesconfig` except 'BME680' configure as [M]
in case you wish to
Hi Ted,
I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk
on m68k, containing mid-90's binaries, from right after the a.out-to-ELF
transition, so I notice if someone breaks old syscall support.
Recently I wanted to change /dev/console on that ramdisk from a symlink
to
Hi Mimi,
On Fri, 2019-01-11 at 10:40 -0500, Mimi Zohar wrote:
> Hi Michael,
>
> On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote:
>
> > Well, there are at least two implementations I know of:
> > For my Lenovo X260 I can choose between Infineon TPM 1.2 or Intel PTT TPM
> > 2.0
> >
Now that thread_info is similar to task_struct, its address is in r2
so CURRENT_THREAD_INFO() macro is useless. This patch removes it.
At the same time, as the 'cpu' field is not anymore in thread_info,
this patch renames it to TASK_CPU.
Signed-off-by: Christophe Leroy
---
thread_info is not anymore in the stack, so the entire stack
can now be used.
There is also no risk anymore of corrupting task_cpu(p) with a
stack overflow so the patch removes the test.
When doing this, an explicit test for NULL stack pointer is
needed in validate_sp() as it is not anymore
The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects thread_info from corruption in the case of stack
overflows.
- Its address is harder to determine if
Some stack pointers used to also be thread_info pointers
and were called tp. Now that they are only stack pointers,
rename them sp.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c | 17 +++--
arch/powerpc/kernel/setup_64.c | 11 +++
2 files changed, 10
Since only the virtual address of allocated blocks is used,
lets use functions returning directly virtual address.
Those functions have the advantage of also zeroing the block.
Suggested-by: Mike Rapoport
Acked-by: Mike Rapoport
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/irq.c
The table of pointers 'current_set' has been used for retrieving
the stack and current. They used to be thread_info pointers as
they were pointing to the stack and current was taken from the
'task' field of the thread_info.
Now, the pointers of 'current_set' table are now both pointers
to
This patch activates CONFIG_THREAD_INFO_IN_TASK which
moves the thread_info into task_struct.
Moving thread_info into task_struct has the following advantages:
- It protects thread_info from corruption in the case of stack
overflows.
- Its address is harder to determine if stack addresses are
When moving to CONFIG_THREAD_INFO_IN_TASK, the thread_info 'cpu' field
gets moved into task_struct and only defined when CONFIG_SMP is set.
This patch ensures that TI_CPU is only used when CONFIG_SMP is set and
that task_struct 'cpu' field is not used directly out of SMP code.
Signed-off-by:
When activating CONFIG_THREAD_INFO_IN_TASK, linux/sched.h
includes asm/current.h. This generates a circular dependency.
To avoid that, asm/processor.h shall not be included in mmu-hash.h
In order to do that, this patch moves into a new header called
asm/task_size_user64.h the information from
This patch cleans the powerpc kernel before activating
CONFIG_THREAD_INFO_IN_TASK:
- The purpose of the pointer given to call_do_softirq() and
call_do_irq() is to point the new stack ==> change it to void* and
rename it 'sp'
- Don't use CURRENT_THREAD_INFO() to locate the stack.
- Fix a few
Now that current_thread_info is located at the beginning of 'current'
task struct, CURRENT_THREAD_INFO macro is not really needed any more.
This patch replaces it by loads of the value at PACACURRENT(r13).
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/exception-64s.h | 4
On Fri, Jan 11, 2019 at 09:12:54PM -0800, Eric Biggers wrote:
> Hi Stephan,
>
> On Fri, Jan 11, 2019 at 08:10:39PM +0100, Stephan Müller wrote:
> > The RFC5869 compliant Key Derivation Function is implemented as a
> > random number generator considering that it behaves like a deterministic
> >
Signed-off-by: George Rimar
Best regards,
George | Developer | Access Softek, Inc
От: Tri Vo
Отправлено: 11 января 2019 г. 23:10
Кому: x...@kernel.org; t...@linutronix.de; mi...@redhat.com; b...@alien8.de;
h...@zytor.com
Копия: George Rimar;
Enable all the i.MX8MQ configs necessary to boot.
Signed-off-by: Abel Vesa
---
arch/arm64/configs/defconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0478ef9..e1d875a 100644
--- a/arch/arm64/configs/defconfig
+++
Hi Jagan.
> On Sat, Jan 12, 2019 at 2:49 AM Sam Ravnborg wrote:
> >
> > Hi Jagan.
> >
> > Gave this another more detailed read - triggered some additional comments.
> > Depite the comments it looks good, and this is all more or
> > less cosmetic improvements.
>
> Thanks for the review.
>
> >
>
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages. This causes some
code duplication which can be easily avoided. GFP_KERNEL allocated and
cleared out pages (__GFP_ZERO) are required for page tables on any given
Hi Jeremy,
> Jeremy Linton hat am 10. Januar 2019 um 00:55
> geschrieben:
>
>
> From: Mian Yousaf Kaukab
>
> Add is_meltdown_safe() which is a whitelist of known safe cores.
>
> Signed-off-by: Mian Yousaf Kaukab
> [Moved location of function]
> Signed-off-by: Jeremy Linton
> ---
>
On Sat, Jan 12, 2019 at 3:44 PM Sam Ravnborg wrote:
>
> Hi Jagan.
>
> > On Sat, Jan 12, 2019 at 2:49 AM Sam Ravnborg wrote:
> > >
> > > Hi Jagan.
> > >
> > > Gave this another more detailed read - triggered some additional comments.
> > > Depite the comments it looks good, and this is all more
Hi again,
On Sat, 2019-01-12 at 10:52 +0100, Michael Niewöhner wrote:
> Hi Mimi,
>
> On Fri, 2019-01-11 at 10:40 -0500, Mimi Zohar wrote:
> > Hi Michael,
> >
> > On Sun, 2018-11-11 at 19:50 +0100, Michael Niewöhner wrote:
> >
> > > Well, there are at least two implementations I know of:
> > >
On 2019/01/12 1:45, Michal Hocko wrote:
>>> Anyway, could you update your patch and abstract
>>> if (unlikely(tsk_is_oom_victim(current) ||
>>> fatal_signal_pending(current) ||
>>> current->flags & PF_EXITING))
>>>
>>> in try_charge and reuse it in
On Fri, Jan 4, 2019 at 8:57 PM Andreas Kemnade wrote:
>
> Hi Marcel,
>
> On Fri, 4 Jan 2019 10:07:34 +0100
> Marcel Holtmann wrote:
>
> > Hi Andreas,
> >
> > Btw. I see nothing standing in the way of merging btuart.c driver and
> > then go from there. Either I dig this out and submit
> >
> > > > > +
> > > > > + msleep(st7701->sleep_delay);
> > > > > +
> > > > > + gpiod_set_value(st7701->reset, 0);
> > > > > +
> > > > > + gpiod_set_value(st7701->reset, 1);
> > > > > +
> > > > > + gpiod_set_value(st7701->reset, 0);
> > > > No timing constrains here? In prepare
On Sat, Jan 12, 2019 at 03:56:38PM +0530, Anshuman Khandual wrote:
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages.
Except that's not true.
> +++ b/arch/x86/mm/pgtable.c
> @@ -13,19 +13,17 @@ phys_addr_t
Hi all,
> Am 12.01.2019 um 12:16 schrieb Jon Nettleton :
>
> On Fri, Jan 4, 2019 at 8:57 PM Andreas Kemnade wrote:
>>
>> Hi Marcel,
>>
>> On Fri, 4 Jan 2019 10:07:34 +0100
>> Marcel Holtmann wrote:
>>
>>> Hi Andreas,
>>>
>>> Btw. I see nothing standing in the way of merging btuart.c
On Sat, Jan 12, 2019 at 02:57:01PM +0800, Changbin Du wrote:
> This patch adds a new trace option 'funcgraph-retval' and is disabled by
> default. When this option is enabled, fgraph tracer will show the return
> value of each function. This is useful to find/analyze a original error
> source in a
Linus,
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus
for you to fetch changes up to
Hi Mathieu,
I think it would be better to simply mask out the minor version number
bits in
function etm4_arch_supported(). That way we can add more intelligence
in there
in the future if we have to and we don't have to touch the calling code
again.
Thanks for the review. Yes it seems
Hi Mathieu,
+
+ etm@704 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ arm,primecell-periphid = <0x000bb95d>;
I'm a little curious as to why you need to bypass the normal AMBA bus
discovery
method by forcing the peripheral ID. Tracers don't
Hi Ben,
On Tue, Dec 18, 2018 at 12:48 AM Martin Blumenstingl
wrote:
>
> Hi Ben,
>
> On Wed, Dec 5, 2018 at 11:15 PM Martin Blumenstingl
> wrote:
> [...]
> > > > Signed-off-by: Ben Dooks
> > > > [resurrected Ben's patches after 2 years]
> > > > Signed-off-by: Martin Blumenstingl
> > >
> > >
On 01/12/2019 05:42 PM, Matthew Wilcox wrote:
> On Sat, Jan 12, 2019 at 03:56:38PM +0530, Anshuman Khandual wrote:
>> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
>> __GFP_ZERO) and using it for allocating page table pages.
>
> Except that's not true.
>
>> +++
On Sat, Jan 12, 2019 at 5:31 PM Sam Ravnborg wrote:
>
> > >
> > > > > > +
> > > > > > + msleep(st7701->sleep_delay);
> > > > > > +
> > > > > > + gpiod_set_value(st7701->reset, 0);
> > > > > > +
> > > > > > + gpiod_set_value(st7701->reset, 1);
> > > > > > +
> > > > > > +
On Sat, Jan 12, 2019 at 11:25:40AM +0900, Masami Hiramatsu wrote:
...
> And I found several functions which must be blacklisted.
> - optprobe template code, which is just a template code and
>never be executed. Moreover, since it can be copied and
>reused, if we probe it, it modifies the
Le 12/01/2019 à 13:12, Matthew Wilcox a écrit :
On Sat, Jan 12, 2019 at 03:56:38PM +0530, Anshuman Khandual wrote:
All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
__GFP_ZERO) and using it for allocating page table pages.
Except that's not true.
+++
On 2019-01-11 10:55 a.m., Arnaldo Carvalho de Melo wrote:
Hi Peter,
bpf_perf_event_open() already returns a value, but if
perf_event_output's output_begin (mostly perf_output_begin) fails,
the only way to know about that is looking before/after the rb->lost,
right?
For ring
Hi Matthew,
On Sat, Jan 12, 2019 at 04:21:13AM -0800, Matthew Wilcox wrote:
> On Sat, Jan 12, 2019 at 02:57:01PM +0800, Changbin Du wrote:
> > This patch adds a new trace option 'funcgraph-retval' and is disabled by
> > default. When this option is enabled, fgraph tracer will show the return
> >
Web Admin Notificación de correo electrónico
Este mensaje se envía desde nuestro centro de mensajería de Web Admin a todos
nuestros propietarios de cuentas de correo electrónico. Estamos eliminando el
acceso a todos nuestros clientes de correo web. Su cuenta de correo electrónico
se
Web Admin Notificación de correo electrónico
Este mensaje se envía desde nuestro centro de mensajería de Web Admin a todos
nuestros propietarios de cuentas de correo electrónico. Estamos eliminando el
acceso a todos nuestros clientes de correo web. Su cuenta de correo electrónico
se
On 11 January 2019 7:37:29 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.4.170 release.
>There are 88 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 11 January 2019 7:37:45 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 3.18.132 release.
>There are 47 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.
>
>From 50465f2a4454625aac622bb84dbecdeaf5a50904 Mon Sep 17 00:00:00 2001
From: "Angelo G. Del Regno"
Date: Sat, 12 Jan 2019 10:52:18 +0100
Subject: [PATCH] clk: qcom: Add MSM8976/56 Global Clock Controller (GCC)
driver
Add support for the global clock controller found on MSM8976
and MSM8976
Hello Scott,
On Fri, Jan 11, 2019 at 01:28:45PM -0800, Scott Branden wrote:
> On 2019-01-11 12:48 p.m., Uwe Kleine-König wrote:
> > On Fri, Jan 11, 2019 at 10:51:14AM +0530, Sheetal Tigadoli wrote:
> > > From: Praveen Kumar B
> > >
> > > Add new compatible string for new version of pwm-kona
> >
Hello,
On Sat, Jan 12, 2019 at 05:08:59PM +1100, Stephen Rothwell wrote:
> On Sat, 12 Jan 2019 17:01:17 +1100 Stephen Rothwell
> wrote:
> >
> > [Reported by "kernelci.org bot" ]
>
> [Also reported by Mark Brown ]
And also reported by the zero-day bot
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
From: Silvio Cesare
Change snprintf to scnprintf. There are generally two cases where using
snprintf causes problems.
1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
In this case, if snprintf would have written more characters than what the
buffer size (SIZE) is, then size will end up
Hi Jagan.
> > But as we just assert reset (set it to 0), this timing constraint can be
> > ignored.
>
> But we unaware of reset pulse duration right? it's the hardware that
> bring the reset assert if we set the line 0. am I correct or do we
> need to explicitly wait 10us after reset initiated?
>From 6aeefad77a2a5d47a9bd009d2d10db2a5dd153a2 Mon Sep 17 00:00:00 2001
From: "Angelo G. Del Regno"
Date: Sat, 12 Jan 2019 16:31:09 +0100
Subject: [PATCH] clk: qcom: smd: Add support for MSM8956/76 RPM clocks
Add all RPM clocks found on MSM8956/MSM8976 SoCs.
Signed-off-by: Angelo G. Del Regno
On Sat, Jan 12, 2019 at 08:27:35PM +0530, Harsh Shandilya wrote:
> On 11 January 2019 7:37:29 PM IST, Greg Kroah-Hartman
> wrote:
> >This is the start of the stable review cycle for the 4.4.170 release.
> >There are 88 patches in this series, all will be posted as a response
> >to this one. If
On Sat, Jan 12, 2019 at 02:49:29PM +0100, Christophe Leroy wrote:
> As far as I can see,
>
> #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
>
> So what's the difference between:
>
> (GFP_KERNEL_ACCOUNT | __GFP_ZERO) & ~__GFP_ACCOUNT
>
> and
>
> (GFP_KERNEL | __GFP_ZERO) &
This patchset adds the necessary bits to wii.dts to enable interrupt
support in the GPIO controller, and defines two GPIO-based buttons,
the POWER button and the EJECT button.
I will send another patchset which will implement interrupt support in
the GPIO driver (gpio-hlwd.c).
Jonathan
The Wii has POWER and EJECT buttons, which are connected through
normalization logic to the GPIO controller (the length of an assertion
of these signals is always the same, regardless of how long the user
pressed the buttons).
Signed-off-by: Jonathan Neuschäfer
---
arch/powerpc/boot/dts/wii.dts
The Hollywood GPIO controller is connected to the Hollywood PIC ()
at IRQs 10 and 11; IRQ 10 for GPIO lines that are configured for access
by the PPC, 11 for GPIO lines that are configured for access by the
ARM926.
Signed-off-by: Jonathan Neuschäfer
---
arch/powerpc/boot/dts/wii.dts | 5 +
Hi everyone,
Did I submit these to the right lists?
If so, could someone please take a look at these patches?
On another note: I think the mailing lists might be a bit overzealous
with respect to what it blocks, I was unable to submit patches using an
@airmail.cc email account.
thanks in
Hi Sam,
On Sat, Jan 12, 2019 at 9:03 PM Sam Ravnborg wrote:
>
> Hi Jagan.
>
> > > But as we just assert reset (set it to 0), this timing constraint can be
> > > ignored.
> >
> > But we unaware of reset pulse duration right? it's the hardware that
> > bring the reset assert if we set the line 0.
On Fri, Jan 11, 2019 at 7:53 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1bdbe2274920 Merge tag 'vfio-v5.0-rc2' of git://github.com..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=177ce96f40
> kernel config:
On Wed, Jan 09, 2019 at 06:57:57PM +0530, Jagan Teki wrote:
> On Tue, Jan 8, 2019 at 2:28 PM Maxime Ripard
> wrote:
> >
> > On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
> > > On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Fri, Dec 21, 2018 at
On Sat, Jan 12, 2019 at 2:27 AM Anshuman Khandual
wrote:
>
> All architectures have been defining their own PGALLOC_GFP as (GFP_KERNEL |
> __GFP_ZERO) and using it for allocating page table pages. This causes some
> code duplication which can be easily avoided. GFP_KERNEL allocated and
> cleared
On Sat, Jan 12, 2019 at 7:50 AM Matthew Wilcox wrote:
>
> On Sat, Jan 12, 2019 at 02:49:29PM +0100, Christophe Leroy wrote:
> > As far as I can see,
> >
> > #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
> >
> > So what's the difference between:
> >
> > (GFP_KERNEL_ACCOUNT | __GFP_ZERO)
Hi Jagan.
> When did .unprepare and .disable are actually called? I turn-off the
> backlight by echo 1 > /sys/class/backlight/backlight/bl_power and even
> power of the board I assume the video transmission stop so it would
> ended-up calling these, but I couldn't see prints. does it the same
>
On Mon, 7 Jan 2019 23:27:48 +0530
Himanshu Jha wrote:
> On Wed, Jan 02, 2019 at 01:25:27PM -0800, Matt Ranostay wrote:
> >
> > > On Dec 24, 2018, at 01:58, Himanshu Jha
> > > wrote:
> > >
> > >> On Fri, Dec 21, 2018 at 03:26:26PM -0800, Amir Mahdi Ghorbanian wrote:
> > >> Replaced bool
...
> > > diff --git a/drivers/staging/iio/addac/adt7316.h
> > > b/drivers/staging/iio/addac/adt7316.h
> > > index fd7c5c92b599..2c72cf3f71cd 100644
> > > --- a/drivers/staging/iio/addac/adt7316.h
> > > +++ b/drivers/staging/iio/addac/adt7316.h
> > > @@ -11,16 +11,13 @@
> > >
> > > #include
On Sun, 6 Jan 2019 11:57:31 +0100
Tomasz Duszynski wrote:
> On Sat, Jan 05, 2019 at 04:54:47PM +, Jonathan Cameron wrote:
> > On Wed, 26 Dec 2018 20:30:35 +0100
> > Tomasz Duszynski wrote:
> >
> > > Sensor can periodically trigger self cleaning. Period can be changed by
> > > writing a
Jacek
On 1/11/19 3:52 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 1/11/19 1:38 PM, Dan Murphy wrote:
>> Jacek
>>
>> Sorry I missed some replies
>>
>> On 1/10/19 4:03 PM, Jacek Anaszewski wrote:
>>> On 1/10/19 9:43 PM, Dan Murphy wrote:
Jacek
On 1/10/19 1:57 PM, Jacek Anaszewski
On 2019-01-11 20:26, Andrey Ryabinin wrote:
On 1/3/19 5:59 PM, Roman Penyaev wrote:
__vmalloc_area_node() calls vfree() on error path, which in turn calls
kmemleak_free(), but area is not yet accounted by kmemleak_vmalloc().
Signed-off-by: Roman Penyaev
Cc: Andrew Morton
Cc: Michal Hocko
UNAME26 is a mechanism to report Linux's version as 2.6.x, for
compatibility with old/broken software. Due to the way it is
implemented, it would have to be updated after 5.0, to keep the
resulting versions unique. Linus Torvalds argued:
> Do we actually need this?
>
> I'd rather let it bitrot,
This comment has been wrong since before git.
Signed-off-by: Jonathan Neuschäfer
---
arch/m68k/apollo/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/apollo/Makefile b/arch/m68k/apollo/Makefile
index 76a057962c38..01856a858fda 100644
---
On Sat, Jan 12, 2019 at 01:58:59PM +0530, Naresh Kamboju wrote:
> On Fri, 11 Jan 2019 at 20:13, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 4.20.2 release.
> > There are 65 patches in this series, all will be posted as a response
> > to this one. If
On 1/11/19 6:07 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.132 release.
There are 47 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.
Responses should be
On 1/11/19 6:07 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.170 release.
There are 88 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.
Responses should be made
On 1/11/19 6:14 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.150 release.
There are 63 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.
Responses should be made
Eric Biggers writes:
> Hi Eric,
>
> The following commit, which went into v4.20, introduced undefined behavior
> when
> sys_rt_sigqueueinfo() is called with sig=0:
Ouch. Good catch.
It looks like the fix is just to do:
diff --git a/include/linux/signal.h b/include/linux/signal.h
index
On 1/11/19 6:13 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.93 release.
There are 105 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.
Responses should be
1 - 100 of 226 matches
Mail list logo
