On Mon 01-10-18 19:59:39, jun qian wrote:
> Header and the corresponding information is not aligned,
> adjust the printing format helps us to understand the slabinfo better.
What prevents you from formating the output when printint the file? In
other words why do we want to do special formating
On Mon 01-10-18 19:59:39, jun qian wrote:
> Header and the corresponding information is not aligned,
> adjust the printing format helps us to understand the slabinfo better.
What prevents you from formating the output when printint the file? In
other words why do we want to do special formating
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Give explicit error for users who want to use larger log buffer.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Suggested-by: Sergey Senozhatsky
So people will
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Add KBUILD_MODNAME to make prints more clear.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Give explicit error for users who want to use larger log buffer.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Suggested-by: Sergey Senozhatsky
So people will
On (09/30/18 00:45), zhe...@windriver.com wrote:
> From: He Zhe
>
> Add KBUILD_MODNAME to make prints more clear.
>
> Signed-off-by: He Zhe
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On (09/30/18 00:45), zhe...@windriver.com wrote:
> Correct wrong casting that might cut off the normal output.
A commit message probably could have been a bit more descriptive,
mentioning that log_first_seq and console_seq are 64-bit unsigned
integers, this is a Cc material potentially.
>
On (09/30/18 00:45), zhe...@windriver.com wrote:
> Correct wrong casting that might cut off the normal output.
A commit message probably could have been a bit more descriptive,
mentioning that log_first_seq and console_seq are 64-bit unsigned
integers, this is a Cc material potentially.
>
On 1 October 2018 at 22:25, Heiko Carstens wrote:
> On Sun, Sep 30, 2018 at 06:49:50PM +0200, Ard Biesheuvel wrote:
>> Commit e872267b8bcbb179 ("jump_table: move entries into ro_after_init
>> region") moved the __jump_table input section into the __ro_after_init
>> output section, but
On 1 October 2018 at 22:25, Heiko Carstens wrote:
> On Sun, Sep 30, 2018 at 06:49:50PM +0200, Ard Biesheuvel wrote:
>> Commit e872267b8bcbb179 ("jump_table: move entries into ro_after_init
>> region") moved the __jump_table input section into the __ro_after_init
>> output section, but
On (09/30/18 00:45), zhe...@windriver.com wrote:
>
> This patch adds a check to prevent the panic.
>
> Signed-off-by: He Zhe
> Cc: sta...@vger.kernel.org
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On (09/30/18 00:45), zhe...@windriver.com wrote:
>
> This patch adds a check to prevent the panic.
>
> Signed-off-by: He Zhe
> Cc: sta...@vger.kernel.org
> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
Reviewed-by: Sergey Senozhatsky
-ss
On Mon, Oct 01, 2018 at 11:14:14AM +0200, Daniel Lezcano wrote:
> On 01/10/2018 03:35, Guo Ren wrote:
> > This timer is used by SMP system and use mfcr/mtcr instruction
> > to access the regs.
> >
> > Changelog:
> > - Remove #define CPUHP_AP_CSKY_TIMER_STARTING
> > - Add
On Mon, Oct 01, 2018 at 11:14:14AM +0200, Daniel Lezcano wrote:
> On 01/10/2018 03:35, Guo Ren wrote:
> > This timer is used by SMP system and use mfcr/mtcr instruction
> > to access the regs.
> >
> > Changelog:
> > - Remove #define CPUHP_AP_CSKY_TIMER_STARTING
> > - Add
On 2 October 2018 at 05:53, Jason A. Donenfeld wrote:
> Hi Arnd,
>
> Apologies for the delay in getting back to you. I had some MTA issues
> and stupidly assumed ARM developers were taking the day off instead...
>
> On Tue, Oct 2, 2018 at 5:33 AM Arnd Bergmann wrote:
>> -arch-$(CONFIG_CPU_32v3)
On 2 October 2018 at 05:53, Jason A. Donenfeld wrote:
> Hi Arnd,
>
> Apologies for the delay in getting back to you. I had some MTA issues
> and stupidly assumed ARM developers were taking the day off instead...
>
> On Tue, Oct 2, 2018 at 5:33 AM Arnd Bergmann wrote:
>> -arch-$(CONFIG_CPU_32v3)
Changes v1 -> v2: Fix PMU_FORMAT_ATTR as Peter suggested
This patch enables uprobes with reference counter in fd-based uprobe.
Highest 32 bits of perf_event_attr.config is used to stored offset
of the reference count (semaphore).
Format information in /sys/bus/event_source/devices/uprobe/format/
Changes v1 -> v2: Fix PMU_FORMAT_ATTR as Peter suggested
This patch enables uprobes with reference counter in fd-based uprobe.
Highest 32 bits of perf_event_attr.config is used to stored offset
of the reference count (semaphore).
Format information in /sys/bus/event_source/devices/uprobe/format/
This is fixed with the following patch.
- Ted
>From c4a928ee604e31354c969b461aa9a6171825096a Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Tue, 2 Oct 2018 01:34:44 -0400
Subject: [PATCH] ext4: fix argument checking in EXT4_IOC_MOVE_EXT
If
This is fixed with the following patch.
- Ted
>From c4a928ee604e31354c969b461aa9a6171825096a Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Tue, 2 Oct 2018 01:34:44 -0400
Subject: [PATCH] ext4: fix argument checking in EXT4_IOC_MOVE_EXT
If
Hi all,
After merging the char-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/nvmem/lpc18xx_eeprom.c: In function 'lpc18xx_eeprom_remove':
drivers/nvmem/lpc18xx_eeprom.c:258:6: warning: unused variable 'ret'
[-Wunused-variable]
int ret;
^~~
Hi all,
After merging the char-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/nvmem/lpc18xx_eeprom.c: In function 'lpc18xx_eeprom_remove':
drivers/nvmem/lpc18xx_eeprom.c:258:6: warning: unused variable 'ret'
[-Wunused-variable]
int ret;
^~~
>
> On Sat, Sep 29, 2018 at 01:30:26AM +0300, Tomas Winkler wrote:
> > Add tpm2_pcr_extend() function to tpm2-cmd.c with signature required
> > by tpm-interface.c. It wraps the original open code implementation.
> > The original original tpm2_pcr_extend() function is renamed to
> >
>
> On Sat, Sep 29, 2018 at 01:30:26AM +0300, Tomas Winkler wrote:
> > Add tpm2_pcr_extend() function to tpm2-cmd.c with signature required
> > by tpm-interface.c. It wraps the original open code implementation.
> > The original original tpm2_pcr_extend() function is renamed to
> >
This reverts commit d76c74387e1c978b6c5524a146ab0f3f72206f98.
While commit d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling")
fixes runtime PM handling when using kgdb, it introduces a traceback for
everyone else.
BUG: sleeping function called from invalid context at
This reverts commit d76c74387e1c978b6c5524a146ab0f3f72206f98.
While commit d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling")
fixes runtime PM handling when using kgdb, it introduces a traceback for
everyone else.
BUG: sleeping function called from invalid context at
TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
for masking interrupts on ast2500 chips, and it's not even listed in
ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
chips.
Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
not
TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
for masking interrupts on ast2500 chips, and it's not even listed in
ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
chips.
Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
not
Hi Russell,
> On 1 October 2018 at 19:56, Russell King - ARM Linux
> wrote:
> We could argue that the ARMv3 assembly files are now stable, so the
> chances of ldrh/strh being introduced is low, which would make this
> change tolerable, but the commit message needs to spell out that
> we lose
Hi Russell,
> On 1 October 2018 at 19:56, Russell King - ARM Linux
> wrote:
> We could argue that the ARMv3 assembly files are now stable, so the
> chances of ldrh/strh being introduced is low, which would make this
> change tolerable, but the commit message needs to spell out that
> we lose
On Mon 01 Oct 02:55 PDT 2018, Niklas Cassel wrote:
> The help text is visible in menuconfig, however QCOM_QMI_HELPERS is a
> hidden kconfig, so it is not selectable in menuconfig.
>
> Remove the help text so that it is more clear that this is intentionally
> a hidden kconfig.
>
> Signed-off-by:
On Mon 01 Oct 02:55 PDT 2018, Niklas Cassel wrote:
> The help text is visible in menuconfig, however QCOM_QMI_HELPERS is a
> hidden kconfig, so it is not selectable in menuconfig.
>
> Remove the help text so that it is more clear that this is intentionally
> a hidden kconfig.
>
> Signed-off-by:
On Mon 01 Oct 03:11 PDT 2018, Niklas Cassel wrote:
> QCOM_QMI_HELPERS is a hidden kconfig, so the proper usage is
> to select it, not depend upon it.
>
> Signed-off-by: Niklas Cassel
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/slimbus/Kconfig | 2 +-
> 1 file changed, 1
On Mon 01 Oct 03:11 PDT 2018, Niklas Cassel wrote:
> QCOM_QMI_HELPERS is a hidden kconfig, so the proper usage is
> to select it, not depend upon it.
>
> Signed-off-by: Niklas Cassel
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/slimbus/Kconfig | 2 +-
> 1 file changed, 1
Hi Ard,
On Tue, Oct 2, 2018 at 5:54 AM Ard Biesheuvel wrote:
> So Arnd's suggestion to switch to armv3-m would actually be feasible
> then? The code in question does not use ldrh only umull, and so it
> should build with armv3m as well. And we will even generate some
> better code for RiscPC if
Hi Ard,
On Tue, Oct 2, 2018 at 5:54 AM Ard Biesheuvel wrote:
> So Arnd's suggestion to switch to armv3-m would actually be feasible
> then? The code in question does not use ldrh only umull, and so it
> should build with armv3m as well. And we will even generate some
> better code for RiscPC if
Hi Arnd,
Apologies for the delay in getting back to you. I had some MTA issues
and stupidly assumed ARM developers were taking the day off instead...
On Tue, Oct 2, 2018 at 5:33 AM Arnd Bergmann wrote:
> -arch-$(CONFIG_CPU_32v3)=-D__LINUX_ARM_ARCH__=3 -march=armv3
>
Hi Arnd,
Apologies for the delay in getting back to you. I had some MTA issues
and stupidly assumed ARM developers were taking the day off instead...
On Tue, Oct 2, 2018 at 5:33 AM Arnd Bergmann wrote:
> -arch-$(CONFIG_CPU_32v3)=-D__LINUX_ARM_ARCH__=3 -march=armv3
>
On Mon 01 Oct 14:49 PDT 2018, Stephen Boyd wrote:
> This code needs to select function #0, which is the first int in the
> array of functions, not the number 0 which may or may not be the
> function for "GPIO mode" per the enum mapping. We were getting lucky on
> SDM845, where this was tested,
On Mon 01 Oct 14:49 PDT 2018, Stephen Boyd wrote:
> This code needs to select function #0, which is the first int in the
> array of functions, not the number 0 which may or may not be the
> function for "GPIO mode" per the enum mapping. We were getting lucky on
> SDM845, where this was tested,
On Mon, Oct 01, 2018 at 06:20:11PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> synchronize_rcu_mult is now obsolete since all the different RCU flavors
> have been consolidated and the API is now common on the updater side.
> sched/core.c is the only user of it. All
On Mon, Oct 01, 2018 at 06:20:11PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> synchronize_rcu_mult is now obsolete since all the different RCU flavors
> have been consolidated and the API is now common on the updater side.
> sched/core.c is the only user of it. All
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean Kim.
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean Kim.
Hi Rob,
Today's linux-next merge of the devicetree tree got a conflict in:
drivers/soc/qcom/apr.c
between commit:
4fadb26574cb ("soc: qcom: apr: Avoid string overflow")
from the qcom tree and commit:
b2efb5b04591 ("soc: Convert to using %pOFn instead of device_node.name")
from the
Hi Rob,
Today's linux-next merge of the devicetree tree got a conflict in:
drivers/soc/qcom/apr.c
between commit:
4fadb26574cb ("soc: qcom: apr: Avoid string overflow")
from the qcom tree and commit:
b2efb5b04591 ("soc: Convert to using %pOFn instead of device_node.name")
from the
On Tue, Oct 2, 2018 at 8:45 AM Atish Patra wrote:
>
> On 9/28/18 11:26 PM, Anup Patel wrote:
> > This patch provides arch_show_interrupts() implementation to
> > show IPI stats via /proc/interrupts.
> >
> > Now the contents of /proc/interrupts" will look like below:
> > CPU0
On Tue, Oct 2, 2018 at 8:45 AM Atish Patra wrote:
>
> On 9/28/18 11:26 PM, Anup Patel wrote:
> > This patch provides arch_show_interrupts() implementation to
> > show IPI stats via /proc/interrupts.
> >
> > Now the contents of /proc/interrupts" will look like below:
> > CPU0
On 9/28/18 11:26 PM, Anup Patel wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0 CPU1 CPU2 CPU3
8: 17 7 6
On 9/28/18 11:26 PM, Anup Patel wrote:
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.
Now the contents of /proc/interrupts" will look like below:
CPU0 CPU1 CPU2 CPU3
8: 17 7 6
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
drivers/mfd/rohm-bd718x7.c:101:23: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
Hi all,
After merging the regulator tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
drivers/mfd/rohm-bd718x7.c:101:23: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
Header and the corresponding information is not aligned,
adjust the printing format helps us to understand the slabinfo better.
Signed-off-by: jun qian
Cc: Barry song <21cn...@gmail.com>
---
mm/slab_common.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
Header and the corresponding information is not aligned,
adjust the printing format helps us to understand the slabinfo better.
Signed-off-by: jun qian
Cc: Barry song <21cn...@gmail.com>
---
mm/slab_common.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
Since 5c2992ee7fd8a29 ("printk: remove console flushing special
cases for partial buffered lines") we don't print cont fragments
to the consoles; cont lines are now proper log_buf entries and
there is no "consecutive continuation flag" anymore: we either
have 'c' entries that mark continuation
Since 5c2992ee7fd8a29 ("printk: remove console flushing special
cases for partial buffered lines") we don't print cont fragments
to the consoles; cont lines are now proper log_buf entries and
there is no "consecutive continuation flag" anymore: we either
have 'c' entries that mark continuation
We have a proper 'overflow' check which tells us that we need to
split up existing cont buffer in separate records:
if (cont.len + len > sizeof(cont.buf))
cont_flush();
At the same time we also have one extra flush: "if cont buffer is
80% full then split it up" in
From: Sergey Senozhatsky
Prior to 5c2992ee7fd8a29 ("printk: remove console flushing special
cases for partial buffered lines") we would do console_cont_flush()
for each pr_cont() to print cont fragments, so console_unlock() would
actually print data:
pr_cont();
console_lock();
We have a proper 'overflow' check which tells us that we need to
split up existing cont buffer in separate records:
if (cont.len + len > sizeof(cont.buf))
cont_flush();
At the same time we also have one extra flush: "if cont buffer is
80% full then split it up" in
From: Sergey Senozhatsky
Prior to 5c2992ee7fd8a29 ("printk: remove console flushing special
cases for partial buffered lines") we would do console_cont_flush()
for each pr_cont() to print cont fragments, so console_unlock() would
actually print data:
pr_cont();
console_lock();
Hello,
RFC
Forked from "printk feature for syzbot". Let's have a separate
discussion thread.
A buch of pr_cont tweaks and cleanups, please see commits and
commits' messages for more details.
Sergey Senozhatsky (3):
printk: keep kernel cont support always
Hello,
RFC
Forked from "printk feature for syzbot". Let's have a separate
discussion thread.
A buch of pr_cont tweaks and cleanups, please see commits and
commits' messages for more details.
Sergey Senozhatsky (3):
printk: keep kernel cont support always
On Mon, Oct 01, 2018 at 04:33:10PM +0100, Phillip Potter wrote:
> Modify ufs_set_de_type function in fs/ufs/util.h to use a lookup
> table rather than a switch statement, as per the TODO comment.
Brittle, that... Something like fs/ext2/dir.c approach (that is,
#define S_SHIFT 12
static unsigned
On Mon, Oct 01, 2018 at 04:33:10PM +0100, Phillip Potter wrote:
> Modify ufs_set_de_type function in fs/ufs/util.h to use a lookup
> table rather than a switch statement, as per the TODO comment.
Brittle, that... Something like fs/ext2/dir.c approach (that is,
#define S_SHIFT 12
static unsigned
We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.
This flag was added by GCC 4.6, and it is recognized by ICC as well.
It is true that Clang does not support this flag but this
We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.
This flag was added by GCC 4.6, and it is recognized by ICC as well.
It is true that Clang does not support this flag but this
From: Girish Mahadevan
New driver for Qualcomm QuadSPI(QSPI) controller that is used to
communicate with slaves such as flash memory devices. The QSPI controller
can operate in 2 or 4 wire mode but only supports SPI Mode 0. The
controller can also operate in Single or Dual data rate modes.
From: Girish Mahadevan
New driver for Qualcomm QuadSPI(QSPI) controller that is used to
communicate with slaves such as flash memory devices. The QSPI controller
can operate in 2 or 4 wire mode but only supports SPI Mode 0. The
controller can also operate in Single or Dual data rate modes.
From: Girish Mahadevan
Bindings for Qualcomm Quad SPI used on SoCs such as sdm845.
Signed-off-by: Girish Mahadevan
Signed-off-by: Ryan Case
---
Changes in v5:
- None
Changes in v4:
- Changed qspi@ to spi@ and device@ to flash@ to match Rob's review
Changes in v3:
- Added generic compatible
From: Girish Mahadevan
Bindings for Qualcomm Quad SPI used on SoCs such as sdm845.
Signed-off-by: Girish Mahadevan
Signed-off-by: Ryan Case
---
Changes in v5:
- None
Changes in v4:
- Changed qspi@ to spi@ and device@ to flash@ to match Rob's review
Changes in v3:
- Added generic compatible
Fix a breakage caused by enabling early tsc initialization which bypasses
a check that disables the forcing of TSC ADJUST to 0 for chassis 0.
This is common on systems where all the chassis start up asynchronously
so which chassis should have a TSC ADJUST value of 0 is not predictable.
The
Fix a breakage caused by enabling early tsc initialization which bypasses
a check that disables the forcing of TSC ADJUST to 0 for chassis 0.
This is common on systems where all the chassis start up asynchronously
so which chassis should have a TSC ADJUST value of 0 is not predictable.
The
Fix regression introduced by
commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")
as it changed setup_arch() so that it now calls tsc_early_init() before
acpi_boot_table_init() which is a necessary step, in the case of UV
systems, to inform tsc_sanitize_first_cpu() that we're on a platform
Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.
This is needed to skip other early setup/init code that might break UV
platform if done too early such as before necessary ACPI tables parsing
takes place.
Signed-off-by:
Fix regression introduced by
commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")
as it changed setup_arch() so that it now calls tsc_early_init() before
acpi_boot_table_init() which is a necessary step, in the case of UV
systems, to inform tsc_sanitize_first_cpu() that we're on a platform
Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.
This is needed to skip other early setup/init code that might break UV
platform if done too early such as before necessary ACPI tables parsing
takes place.
Signed-off-by:
Em Mon, 1 Oct 2018 15:43:13 -0700
"Luck, Tony" escreveu:
> Nobody(*) uses them. Dropping this will allow us to make the total
> number of memory controllers configurable (as we won't have to
> worry about duplicated device names under this directory).
>
> (*)
Em Mon, 1 Oct 2018 15:43:13 -0700
"Luck, Tony" escreveu:
> Nobody(*) uses them. Dropping this will allow us to make the total
> number of memory controllers configurable (as we won't have to
> worry about duplicated device names under this directory).
>
> (*)
From: "Joel Fernandes (Google)"
sched/core.c was the only user of synchronize_rcu_mult. It has been
coverted to use synchronize_rcu. So lets remove the synchronize_rcu_mult
implementation entirely.
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rcupdate_wait.h | 17 -
From: "Joel Fernandes (Google)"
synchronize_rcu_mult is now obsolete since all the different RCU flavors
have been consolidated and the API is now common on the updater side.
sched/core.c is the only user of it. All call_rcu_ calls boil
down to the same call_rcu. So there's no point in calling
From: "Joel Fernandes (Google)"
sched/core.c was the only user of synchronize_rcu_mult. It has been
coverted to use synchronize_rcu. So lets remove the synchronize_rcu_mult
implementation entirely.
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rcupdate_wait.h | 17 -
From: "Joel Fernandes (Google)"
synchronize_rcu_mult is now obsolete since all the different RCU flavors
have been consolidated and the API is now common on the updater side.
sched/core.c is the only user of it. All call_rcu_ calls boil
down to the same call_rcu. So there's no point in calling
From: Girish Mahadevan
Bindings for Qualcomm Quad SPI used on SoCs such as sdm845.
Signed-off-by: Girish Mahadevan
Signed-off-by: Ryan Case
---
Changes in v4:
- Changed qspi@ to spi@ and device@ to flash@ to match Rob's review
Changes in v3:
- Added generic compatible string in addition to
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pcie-idio-24.c | 102 +++
1 file changed, 36 insertions(+), 66
From: Girish Mahadevan
Bindings for Qualcomm Quad SPI used on SoCs such as sdm845.
Signed-off-by: Girish Mahadevan
Signed-off-by: Ryan Case
---
Changes in v4:
- Changed qspi@ to spi@ and device@ to flash@ to match Rob's review
Changes in v3:
- Added generic compatible string in addition to
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pcie-idio-24.c | 102 +++
1 file changed, 36 insertions(+), 66
From: Girish Mahadevan
New driver for Qualcomm QuadSPI(QSPI) controller that is used to
communicate with slaves such as flash memory devices. The QSPI controller
can operate in 2 or 4 wire mode but only supports SPI Mode 0. The
controller can also operate in Single or Dual data rate modes.
From: Girish Mahadevan
New driver for Qualcomm QuadSPI(QSPI) controller that is used to
communicate with slaves such as flash memory devices. The QSPI controller
can operate in 2 or 4 wire mode but only supports SPI Mode 0. The
controller can also operate in Single or Dual data rate modes.
пн, 1 окт. 2018 г. в 17:59, Rodrigo Freire :
>
> By default, no messages are printed when mounting a CIFS filesystem.
> This information is valuable when troubleshooting and/or forensic
> analyzing a system and finding out if was a CIFS endpoint mount
> attempted.
> Other filesystems such as XFS,
пн, 1 окт. 2018 г. в 17:59, Rodrigo Freire :
>
> By default, no messages are printed when mounting a CIFS filesystem.
> This information is valuable when troubleshooting and/or forensic
> analyzing a system and finding out if was a CIFS endpoint mount
> attempted.
> Other filesystems such as XFS,
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pci-idio-16.c | 67 +++--
1 file changed, 21 insertions(+), 46
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-pci-idio-16.c | 67 +++--
1 file changed, 21 insertions(+), 46
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-ws16c48.c | 66 +
1 file changed, 16 insertions(+), 50
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-gpio-mm.c | 67 +
1 file changed, 16 insertions(+), 51
On Mon, Oct 01, 2018 at 05:47:57AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 01, 2018 at 04:11:27PM +1000, Dave Chinner wrote:
> > This reminds me so much of Linux mmap() in the mid-2000s - mmap()
> > worked for ext3 without being aware of page faults,
>
> And "worked" still is a bit of a
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-idi-48.c | 32
1 file changed, 4 insertions(+), 28
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-dio-48e.c | 67 -
1 file changed, 16 insertions(+), 51
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-ws16c48.c | 66 +
1 file changed, 16 insertions(+), 50
Replace verbose implementation in get_multiple/set_multiple callbacks
with for_each_set_clump macro to simplify code and improve clarity.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-gpio-mm.c | 67 +
1 file changed, 16 insertions(+), 51
On Mon, Oct 01, 2018 at 05:47:57AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 01, 2018 at 04:11:27PM +1000, Dave Chinner wrote:
> > This reminds me so much of Linux mmap() in the mid-2000s - mmap()
> > worked for ext3 without being aware of page faults,
>
> And "worked" still is a bit of a
1 - 100 of 1182 matches
Mail list logo
