On 24 October 2018 at 10:01, Chunyan Zhang wrote:
> The function sdhci_allocate_bounce_buffer() always return zero at
> present, so there's no need to have a return value, that will also make
> error path easier.
>
> CC: Linus Walleij
> Signed-off-by: Chunyan Zhang
This looks good to me,
On 24 October 2018 at 10:01, Chunyan Zhang wrote:
> The function sdhci_allocate_bounce_buffer() always return zero at
> present, so there's no need to have a return value, that will also make
> error path easier.
>
> CC: Linus Walleij
> Signed-off-by: Chunyan Zhang
This looks good to me,
On Wed, Oct 24, 2018 at 10:47:24AM +0300, Meelis Roos wrote:
> > Would you mind opening a report at https://bugzilla.kernel.org? I'm
> > not sure if anybody will be able to do anything about this, but it's
> > always possible.
>
> Submitted now, https://bugzilla.kernel.org/show_bug.cgi?id=201503
On Wed, Oct 24, 2018 at 10:47:24AM +0300, Meelis Roos wrote:
> > Would you mind opening a report at https://bugzilla.kernel.org? I'm
> > not sure if anybody will be able to do anything about this, but it's
> > always possible.
>
> Submitted now, https://bugzilla.kernel.org/show_bug.cgi?id=201503
Linus,
please pull the latest printk changes from
git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk
tags/printk-for-4.20
==
- Fix two more locations where printf formatting leaked pointers.
- Better log_buf_len parameter handling.
- Add prefix to messages from
Linus,
please pull the latest printk changes from
git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk
tags/printk-for-4.20
==
- Fix two more locations where printf formatting leaked pointers.
- Better log_buf_len parameter handling.
- Add prefix to messages from
On Tue, Oct 23, 2018 at 5:08 AM Al Viro wrote:
>
> compat_ioctl work related to tty ioctls.
Pulled,
Linus
On Tue, Oct 23, 2018 at 5:08 AM Al Viro wrote:
>
> compat_ioctl work related to tty ioctls.
Pulled,
Linus
On Mon, Oct 22, 2018 at 3:24 PM Kees Cook wrote:
>
> Please pull these pstore changes for v4.20-rc1.
Pulled,
Linus
On Mon, Oct 22, 2018 at 3:24 PM Kees Cook wrote:
>
> Please pull these pstore changes for v4.20-rc1.
Pulled,
Linus
On Wed, Oct 24, 2018 at 3:37 AM Takashi Iwai wrote:
>
> On Wed, 10 Oct 2018 19:49:23 +0200,
> Connor McAdams wrote:
> >
> > The following changes since commit c6b6265d718d118e28e1ce8f91769aa886b54c94:
> >
> > Merge tag 'iwlwifi-fw-2018-10-03' of
> >
On Wed, Oct 24, 2018 at 3:37 AM Takashi Iwai wrote:
>
> On Wed, 10 Oct 2018 19:49:23 +0200,
> Connor McAdams wrote:
> >
> > The following changes since commit c6b6265d718d118e28e1ce8f91769aa886b54c94:
> >
> > Merge tag 'iwlwifi-fw-2018-10-03' of
> >
On Wed, Oct 24, 2018 at 12:35:00AM +0300, Igor Stoppa wrote:
> Some of the data structures used in list management are composed by two
> pointers. Since the kernel is now configured by default to randomize the
> layout of data structures soleley composed by pointers,
Isn't this true for function
On Wed, Oct 24, 2018 at 12:35:00AM +0300, Igor Stoppa wrote:
> Some of the data structures used in list management are composed by two
> pointers. Since the kernel is now configured by default to randomize the
> layout of data structures soleley composed by pointers,
Isn't this true for function
Hi!
> >> The LM3697 is a single function LED driver. The single function LED
> >> driver needs to reside in the LED directory as a dedicated LED driver
> >> and not as a MFD device. The device does have common brightness and ramp
> >
> > So it is single function LED driver. That does not mean
Hi!
> >> The LM3697 is a single function LED driver. The single function LED
> >> driver needs to reside in the LED directory as a dedicated LED driver
> >> and not as a MFD device. The device does have common brightness and ramp
> >
> > So it is single function LED driver. That does not mean
gpiod_request_commit() copies the pointer to the label
passed as an argument only to be used later. But there's a
chance the caller could immediately free the passed string
(e.g., local variable). This could trigger a use after free
when we use gpio label(e.g., gpiochip_unlock_as_irq(),
gpiod_request_commit() copies the pointer to the label
passed as an argument only to be used later. But there's a
chance the caller could immediately free the passed string
(e.g., local variable). This could trigger a use after free
when we use gpio label(e.g., gpiochip_unlock_as_irq(),
Please Cc DT list for bindings.
On Wed, Oct 24, 2018 at 4:01 AM Peng Hao wrote:
>
Commit message?
"dt-bindings: misc: ..." for the subject.
> Signed-off-by: Peng Hao
> ---
> .../devicetree/bindings/arm/pvpanic-mmio.txt | 29
> ++
As Mark said, not ARM specific. So
Please Cc DT list for bindings.
On Wed, Oct 24, 2018 at 4:01 AM Peng Hao wrote:
>
Commit message?
"dt-bindings: misc: ..." for the subject.
> Signed-off-by: Peng Hao
> ---
> .../devicetree/bindings/arm/pvpanic-mmio.txt | 29
> ++
As Mark said, not ARM specific. So
Enke Chen writes:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to
Enke Chen writes:
> For simplicity and consistency, this patch provides an implementation
> for signal-based fault notification prior to the coredump of a child
> process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
> be used by an application to express its interest and to
On 23/10/2018 18:03, Jerome Brunet wrote:
> If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set()
> with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will
> force a pull-down bias on the pin.
>
> Instead of the pull type register bank, the driver should
On Mon, 2018-10-08 at 11:43 +0800, Houlong Wei wrote:
> Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
>
> Signed-off-by: Houlong Wei
> Signed-off-by: HS Liao
> ---
> drivers/soc/mediatek/Kconfig | 12 ++
> drivers/soc/mediatek/Makefile |1 +
>
On 23/10/2018 18:03, Jerome Brunet wrote:
> If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set()
> with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will
> force a pull-down bias on the pin.
>
> Instead of the pull type register bank, the driver should
On Mon, 2018-10-08 at 11:43 +0800, Houlong Wei wrote:
> Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.
>
> Signed-off-by: Houlong Wei
> Signed-off-by: HS Liao
> ---
> drivers/soc/mediatek/Kconfig | 12 ++
> drivers/soc/mediatek/Makefile |1 +
>
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 04:58
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re:
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 04:58
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re:
On Wed, Oct 24, 2018 at 12:54:46PM +, Pascal PAILLET-LME wrote:
> I'm sorry, I'm not sure to understand. Would you prefer to not register
> regulators that
> are not described in the device-tree ?
No, I'm saying register all regulators regardless of if they are in the
device tree - you
On Wed 2018-10-24 07:27:57, Dan Murphy wrote:
> Pavel
>
> On 10/24/2018 04:14 AM, Pavel Machek wrote:
> > On Tue 2018-10-23 12:06:17, Dan Murphy wrote:
> >> From: Pavel Machek
> >>
> >> This adds backlight support for the following TI LMU
> >> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and
On Wed 2018-10-24 07:27:57, Dan Murphy wrote:
> Pavel
>
> On 10/24/2018 04:14 AM, Pavel Machek wrote:
> > On Tue 2018-10-23 12:06:17, Dan Murphy wrote:
> >> From: Pavel Machek
> >>
> >> This adds backlight support for the following TI LMU
> >> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and
On Wed, Oct 24, 2018 at 12:54:46PM +, Pascal PAILLET-LME wrote:
> I'm sorry, I'm not sure to understand. Would you prefer to not register
> regulators that
> are not described in the device-tree ?
No, I'm saying register all regulators regardless of if they are in the
device tree - you
On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>
> I doubt it was copied - more likely independent evolution.
> But on reflection, I see that it is probably reasonable that it
> shouldn't be used this way - or at all in this context.
> I'll try to understand what the issues really are
On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>
> I doubt it was copied - more likely independent evolution.
> But on reflection, I see that it is probably reasonable that it
> shouldn't be used this way - or at all in this context.
> I'll try to understand what the issues really are
On Wed, Oct 24, 2018 at 12:02 PM Peng Hao wrote:
>
> By default, when ACPI tables and FDT coexist for ARM64,
> current kernel takes precedence over FDT to get device information.
> This patch increases the way to get information through FDT.
> * pvpanic.c - pvpanic Device Support
> *
> *
On Wed, Oct 24, 2018 at 12:02 PM Peng Hao wrote:
>
> By default, when ACPI tables and FDT coexist for ARM64,
> current kernel takes precedence over FDT to get device information.
> This patch increases the way to get information through FDT.
> * pvpanic.c - pvpanic Device Support
> *
> *
On Wed, Oct 24, 2018 at 03:51:11PM +0300, Kirill A. Shutemov wrote:
> +++ b/Documentation/x86/x86_64/mm.txt
> @@ -34,23 +34,24 @@
> __||__|_|___
>
>
On Wed, Oct 24, 2018 at 03:51:11PM +0300, Kirill A. Shutemov wrote:
> +++ b/Documentation/x86/x86_64/mm.txt
> @@ -34,23 +34,24 @@
> __||__|_|___
>
>
On Wed, Oct 24, 2018 at 12:02 PM Peng Hao wrote:
>
> On some architectures (e.g. arm64), it's preferable to use MMIO, since
> this can be used standalone. Add MMIO support to the pvpanic driver.
>
No global variables, please.
If your switch to ioreadxx()iowritexx() it would really help you
On Wed, Oct 24, 2018 at 12:02 PM Peng Hao wrote:
>
> On some architectures (e.g. arm64), it's preferable to use MMIO, since
> this can be used standalone. Add MMIO support to the pvpanic driver.
>
No global variables, please.
If your switch to ioreadxx()iowritexx() it would really help you
On Wed, Oct 24, 2018 at 12:02 PM Peng Hao wrote:
>
> move pvpanic.c from drivers/platform/x86 to drivers/misc.
> following patches will use pvpanic device in arm64.
>
-C -M usually helps in such patches.
The question is perhaps this should go under drivers/acpi?
Rafael, what do you think?
>
On Wed, Oct 24, 2018 at 12:02 PM Peng Hao wrote:
>
> move pvpanic.c from drivers/platform/x86 to drivers/misc.
> following patches will use pvpanic device in arm64.
>
-C -M usually helps in such patches.
The question is perhaps this should go under drivers/acpi?
Rafael, what do you think?
>
On Fri, Oct 19, 2018 at 06:15:31PM +0100, Dan O'Donovan wrote:
> Hi all,
>
> This series adds platform support for AAEON's UP Squared, a x86 SBC
> based on Apollo Lake [1]. Specifically, it enables control for the board
> pin headers and for the LEDs, as both of these features are only
>
On Fri, Oct 19, 2018 at 06:15:31PM +0100, Dan O'Donovan wrote:
> Hi all,
>
> This series adds platform support for AAEON's UP Squared, a x86 SBC
> based on Apollo Lake [1]. Specifically, it enables control for the board
> pin headers and for the LEDs, as both of these features are only
>
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
Shouldn't this be in include/uapi/linux/fs_types.h?
One of things which must be made crystal clear is these definitions
MUST NOT ever change. It would break the
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> diff --git a/include/linux/file_type.h b/include/linux/file_type.h
Shouldn't this be in include/uapi/linux/fs_types.h?
One of things which must be made crystal clear is these definitions
MUST NOT ever change. It would break the
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:19
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re:
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:19
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re:
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:47
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re:
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:47
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
> Subject: Re:
Hello Mark,
Le 10/19/2018 01:50 PM, Mark Brown a écrit :
> On Thu, Oct 18, 2018 at 09:02:12AM +, Pascal PAILLET-LME wrote:
>
>> +for (i = 0; i < ARRAY_SIZE(stpmic1_regulator_cfgs); i++) {
>> +/* Parse DT & find regulators to register */
>> +init_data =
Hello Mark,
Le 10/19/2018 01:50 PM, Mark Brown a écrit :
> On Thu, Oct 18, 2018 at 09:02:12AM +, Pascal PAILLET-LME wrote:
>
>> +for (i = 0; i < ARRAY_SIZE(stpmic1_regulator_cfgs); i++) {
>> +/* Parse DT & find regulators to register */
>> +init_data =
On Tue, Oct 16, 2018 at 6:21 AM Daniel Lezcano
wrote:
>
> On 16/10/2018 05:01, Andy Tang wrote:
> > Hi Daniel,
> >
> > Please see my reply inline.
> >
> >> -Original Message-
>
> [ ... ]
>
> >> I'm proposing to move struct qoriq_tmu_site_regs inside the struct
> >> qoriq_sensor.
> >>
> >>
On Tue, Oct 16, 2018 at 6:21 AM Daniel Lezcano
wrote:
>
> On 16/10/2018 05:01, Andy Tang wrote:
> > Hi Daniel,
> >
> > Please see my reply inline.
> >
> >> -Original Message-
>
> [ ... ]
>
> >> I'm proposing to move struct qoriq_tmu_site_regs inside the struct
> >> qoriq_sensor.
> >>
> >>
On Wed, 2018-10-24 at 07:53 +0200, Ingo Molnar wrote:
> * Rik van Riel wrote:
>
> > The big thing remaining is the reference count overhead of
> > the lazy TLB mm_struct, but getting rid of that is rather a
> > lot of code for a small performance gain. Not quite what
> > Linus asked for :)
>
>
The patchset fixes issues with LDT remap for PTI:
- Layout collision due to KASLR with 5-level paging;
- Information leak via Meltdown-like attack;
Please review and consider applying.
v2:
- Rebase to the Linus' tree
+ fix conflict with new documentation of kernel memory layout
+ fix
On Wed, 2018-10-24 at 07:53 +0200, Ingo Molnar wrote:
> * Rik van Riel wrote:
>
> > The big thing remaining is the reference count overhead of
> > the lazy TLB mm_struct, but getting rid of that is rather a
> > lot of code for a small performance gain. Not quite what
> > Linus asked for :)
>
>
The patchset fixes issues with LDT remap for PTI:
- Layout collision due to KASLR with 5-level paging;
- Information leak via Meltdown-like attack;
Please review and consider applying.
v2:
- Rebase to the Linus' tree
+ fix conflict with new documentation of kernel memory layout
+ fix
modify_ldt(2) leaves old LDT mapped after we switch over to the new one.
Memory for the old LDT gets freed and the pages can be re-used.
Leaving the mapping in place can have security implications. The mapping
is present in userspace copy of page tables and Meltdown-like attack can
read these
On 5-level paging LDT remap area is placed in the middle of
KASLR randomization region and it can overlap with direct mapping,
vmalloc or vmap area.
Let's move LDT just before direct mapping which makes it safe for KASLR.
This also allows us to unify layout between 4- and 5-level paging.
We
modify_ldt(2) leaves old LDT mapped after we switch over to the new one.
Memory for the old LDT gets freed and the pages can be re-used.
Leaving the mapping in place can have security implications. The mapping
is present in userspace copy of page tables and Meltdown-like attack can
read these
On 5-level paging LDT remap area is placed in the middle of
KASLR randomization region and it can overlap with direct mapping,
vmalloc or vmap area.
Let's move LDT just before direct mapping which makes it safe for KASLR.
This also allows us to unify layout between 4- and 5-level paging.
We
On Wed, Oct 24, 2018 at 04:54:47AM -0700, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 07:31:56PM +0300, Kirill A. Shutemov wrote:
> > -8800 - c7ff (=64 TB) direct mapping of all phys.
> > memory
> > +8880 - 887f (=39 bits) LDT remap for PTI
>
>
On Wed, Oct 24, 2018 at 04:54:47AM -0700, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 07:31:56PM +0300, Kirill A. Shutemov wrote:
> > -8800 - c7ff (=64 TB) direct mapping of all phys.
> > memory
> > +8880 - 887f (=39 bits) LDT remap for PTI
>
>
On 10/24/18 1:49 PM, Jon Hunter wrote:
>
> On 22/10/2018 12:19, Dmitry Osipenko wrote:
>> On 10/22/18 12:52 PM, Thierry Reding wrote:
>>> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote:
From: Jonathan Hunter
The tps6586x driver creates an irqchip that is used by its
On 10/24/18 1:49 PM, Jon Hunter wrote:
>
> On 22/10/2018 12:19, Dmitry Osipenko wrote:
>> On 10/22/18 12:52 PM, Thierry Reding wrote:
>>> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote:
From: Jonathan Hunter
The tps6586x driver creates an irqchip that is used by its
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:49
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
> Subject: Re:
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:49
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
> Subject: Re:
Najdroższy w Chrystusie,
Jestem panią Ruth Hamson, ożeniłem się z panem Paulem Hamsonem przez 19 lat bez
dziecka, a mój mąż zmarł w 2007 roku. Kontaktuję się z Państwem, abyście
wiedzieli, że pragnę przekazać sumę 6 500 000 USD, którą odziedziczyłem po
spóźniony mąż na cele charytatywne,
Najdroższy w Chrystusie,
Jestem panią Ruth Hamson, ożeniłem się z panem Paulem Hamsonem przez 19 lat bez
dziecka, a mój mąż zmarł w 2007 roku. Kontaktuję się z Państwem, abyście
wiedzieli, że pragnę przekazać sumę 6 500 000 USD, którą odziedziczyłem po
spóźniony mąż na cele charytatywne,
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:22
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
>
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 03:22
> To: Wendy Liang ; Loic PALLARDY
>
> Cc: Bjorn Andersson ; Ohad Ben-Cohen
> ; linux-remotep...@vger.kernel.org; Linux Kernel
> Mailing List ; Arnaud POULIQUEN
> ; benjamin.gaign...@linaro.org
>
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> +static inline unsigned char fs_dtype(int filetype)
That "int" is asking for trouble, especially since negative
argument will blow up. And it comes from untrusted source...
> +{
> + if (filetype >= FT_MAX)
> +
On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> +static inline unsigned char fs_dtype(int filetype)
That "int" is asking for trouble, especially since negative
argument will blow up. And it comes from untrusted source...
> +{
> + if (filetype >= FT_MAX)
> +
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:02
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
>
Hi Suman,
> -Original Message-
> From: Suman Anna
> Sent: mercredi 24 octobre 2018 05:02
> To: Loic PALLARDY ; bjorn.anders...@linaro.org;
> o...@wizery.com
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Arnaud POULIQUEN ;
> benjamin.gaign...@linaro.org
>
On Wed 17-10-18 08:26:20, Alexander Duyck wrote:
[...]
> With that said I am also wondering if a possible solution to the complaints
> you had would be to look at just exporting the __init_pageblock function
> later and moving the call to memmap_init_zone_device out to the memremap or
> hotplug
On Wed 17-10-18 08:26:20, Alexander Duyck wrote:
[...]
> With that said I am also wondering if a possible solution to the complaints
> you had would be to look at just exporting the __init_pageblock function
> later and moving the call to memmap_init_zone_device out to the memremap or
> hotplug
Pavel
On 10/24/2018 04:14 AM, Pavel Machek wrote:
> On Tue 2018-10-23 12:06:17, Dan Murphy wrote:
>> From: Pavel Machek
>>
>> This adds backlight support for the following TI LMU
>> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
>>
>> It controls LEDs on Droid 4
>> smartphone,
Pavel
On 10/24/2018 04:14 AM, Pavel Machek wrote:
> On Tue 2018-10-23 12:06:17, Dan Murphy wrote:
>> From: Pavel Machek
>>
>> This adds backlight support for the following TI LMU
>> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
>>
>> It controls LEDs on Droid 4
>> smartphone,
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> On Sun, Oct 21 2018, Josh Triplett wrote:
>
> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> I call on you, Greg:
> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> - to revert
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> On Sun, Oct 21 2018, Josh Triplett wrote:
>
> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> I call on you, Greg:
> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> - to revert
Date::
Wednesday, October 24th, 2018.
WITH DUE RESPECT:
Let me start by introduce myself; I am Mrs.Ruth Yoda, Bill and
Exchange manager (Bank of Africa) Ouagadougou, Burkina Faso. I write
you this letter based on the latest development at our bank which i
will like to bring to your personal
Date::
Wednesday, October 24th, 2018.
WITH DUE RESPECT:
Let me start by introduce myself; I am Mrs.Ruth Yoda, Bill and
Exchange manager (Bank of Africa) Ouagadougou, Burkina Faso. I write
you this letter based on the latest development at our bank which i
will like to bring to your personal
Pavel
On 10/24/2018 04:04 AM, Pavel Machek wrote:
> Hi!
>
>> The LM3697 is a single function LED driver. The single function LED
>> driver needs to reside in the LED directory as a dedicated LED driver
>> and not as a MFD device. The device does have common brightness and ramp
>
> So it is
Pavel
On 10/24/2018 04:04 AM, Pavel Machek wrote:
> Hi!
>
>> The LM3697 is a single function LED driver. The single function LED
>> driver needs to reside in the LED directory as a dedicated LED driver
>> and not as a MFD device. The device does have common brightness and ramp
>
> So it is
On 19/10/18 22:50, luca abeni wrote:
> On Fri, 19 Oct 2018 13:39:42 +0200
> Peter Zijlstra wrote:
>
> > On Thu, Oct 18, 2018 at 01:08:11PM +0200, luca abeni wrote:
> > > Ok, I see the issue now: the problem is that the "while
> > > (dl_se->runtime <= 0)" loop is executed at replenishment time,
On 19/10/18 22:50, luca abeni wrote:
> On Fri, 19 Oct 2018 13:39:42 +0200
> Peter Zijlstra wrote:
>
> > On Thu, Oct 18, 2018 at 01:08:11PM +0200, luca abeni wrote:
> > > Ok, I see the issue now: the problem is that the "while
> > > (dl_se->runtime <= 0)" loop is executed at replenishment time,
On 23/10/18 23:19, Phillip Potter wrote:
> Deduplicate the exofs file type conversion implementation.
>
> Original patch by Amir Goldstein.
>
> v2:
> - This version does not remove EXOFS_FT_x enum from fs/exofs/common.h,
> as these values are now used in compile-time checks added by
>
On 23/10/18 23:19, Phillip Potter wrote:
> Deduplicate the exofs file type conversion implementation.
>
> Original patch by Amir Goldstein.
>
> v2:
> - This version does not remove EXOFS_FT_x enum from fs/exofs/common.h,
> as these values are now used in compile-time checks added by
>
On Tue, 23 Oct 2018, Jessica Yu wrote:
> diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
> index f0690c2ca3e0..05067717dfc5 100644
> --- a/arch/arm64/kernel/module-plts.c
> +++ b/arch/arm64/kernel/module-plts.c
> @@ -210,9 +210,15 @@ int
On Tue, 23 Oct 2018, Jessica Yu wrote:
> diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
> index f0690c2ca3e0..05067717dfc5 100644
> --- a/arch/arm64/kernel/module-plts.c
> +++ b/arch/arm64/kernel/module-plts.c
> @@ -210,9 +210,15 @@ int
On Tue, Oct 23, 2018 at 07:31:56PM +0300, Kirill A. Shutemov wrote:
> -8800 - c7ff (=64 TB) direct mapping of all phys.
> memory
> +8880 - 887f (=39 bits) LDT remap for PTI
I'm a little bit cross-eyed at this point, but I think the above '888'
On Tue, Oct 23, 2018 at 07:31:56PM +0300, Kirill A. Shutemov wrote:
> -8800 - c7ff (=64 TB) direct mapping of all phys.
> memory
> +8880 - 887f (=39 bits) LDT remap for PTI
I'm a little bit cross-eyed at this point, but I think the above '888'
- On Oct 23, 2018, at 10:35 PM, Igor Stoppa igor.sto...@gmail.com wrote:
> In some cases, all the data needing protection can be allocated from a pool
> in one go, as directly writable, then initialized and protected.
> The sequence is relatively short and it's acceptable to leave the entire
- On Oct 23, 2018, at 10:35 PM, Igor Stoppa igor.sto...@gmail.com wrote:
> In some cases, all the data needing protection can be allocated from a pool
> in one go, as directly writable, then initialized and protected.
> The sequence is relatively short and it's acceptable to leave the entire
On Tue, Oct 23, 2018 at 11:15:03AM -0700, David Miller wrote:
> From: Arnaldo Carvalho de Melo
> Date: Tue, 23 Oct 2018 15:05:03 -0300
>
> > IIRC this was first done for 'perf record', where we have to stash those
> > events in the perf.data file, to then, later, 'perf report' to process
> >
On Tue, Oct 23, 2018 at 11:15:03AM -0700, David Miller wrote:
> From: Arnaldo Carvalho de Melo
> Date: Tue, 23 Oct 2018 15:05:03 -0300
>
> > IIRC this was first done for 'perf record', where we have to stash those
> > events in the perf.data file, to then, later, 'perf report' to process
> >
FROM: DR. JONATHAN JUJU
ACH REPUBLIC OF SOUTH AFRICA.
Attn: Sir/Ma
YOUR COMPANY'S OPERATIONS AND PROFILE GOT MY ATTENTION, IN LINE WITH
MY CURRENT DIVERSIFICATION AND EXPANSION PROGRAM IN CREATING
STRATEGIC PARTNERSHIP I WOULD LIKE TO KNOW IF THERE ARE AVAILABLE
PARTNERSHIP OPTIONS AND
FROM: DR. JONATHAN JUJU
ACH REPUBLIC OF SOUTH AFRICA.
Attn: Sir/Ma
YOUR COMPANY'S OPERATIONS AND PROFILE GOT MY ATTENTION, IN LINE WITH
MY CURRENT DIVERSIFICATION AND EXPANSION PROGRAM IN CREATING
STRATEGIC PARTNERSHIP I WOULD LIKE TO KNOW IF THERE ARE AVAILABLE
PARTNERSHIP OPTIONS AND
501 - 600 of 914 matches
Mail list logo
