Re: [PATCH 0/2] Add devicetree for Axentia Nattis

On 2017-12-02 02:05, Javier Martinez Canillas wrote: > Hello Peter, > > On Fri, Dec 1, 2017 at 11:44 PM, Peter Rosin wrote: >> Hi! >> >> I'd like to add a devicetree for our Nattis to the kernel. The >> Nattis is a device for showing departures for public transportation >>

Re: [PATCH 0/2] Add devicetree for Axentia Nattis

On 2017-12-02 02:05, Javier Martinez Canillas wrote: > Hello Peter, > > On Fri, Dec 1, 2017 at 11:44 PM, Peter Rosin wrote: >> Hi! >> >> I'd like to add a devicetree for our Nattis to the kernel. The >> Nattis is a device for showing departures for public transportation >> (optionally including

RE: [PATCH 01/43] x86/decoder: Add new TEST instruction pattern

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Ingo Molnar > Sent: Friday, November 24, 2017 3:14 AM > To: linux-kernel@vger.kernel.org > Subject: [PATCH 01/43] x86/decoder: Add new TEST instruction pattern > >

RE: [PATCH 01/43] x86/decoder: Add new TEST instruction pattern

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Ingo Molnar > Sent: Friday, November 24, 2017 3:14 AM > To: linux-kernel@vger.kernel.org > Subject: [PATCH 01/43] x86/decoder: Add new TEST instruction pattern > >

[PATCH v2] net: macb: change GFP_KERNEL to GFP_ATOMIC

Function gem_add_flow_filter called on line 2958 inside lock on line 2949 but uses GFP_KERNEL Generated by: scripts/coccinelle/locks/call_kern.cocci Fixes: ae8223de3df5 ("net: macb: Added support for RX filtering") CC: Rafal Ozieblo Signed-off-by: Julia Lawall

[PATCH v2] net: macb: change GFP_KERNEL to GFP_ATOMIC

Function gem_add_flow_filter called on line 2958 inside lock on line 2949 but uses GFP_KERNEL Generated by: scripts/coccinelle/locks/call_kern.cocci Fixes: ae8223de3df5 ("net: macb: Added support for RX filtering") CC: Rafal Ozieblo Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu ---

Re: [PATCH 16/21] x86/entry/64: Use a per-CPU trampoline stack for IDT entries

> From: Dave Hansen > > The "SYSENTER" stack is used for a lot more than SYSENTER now. > Give it a better string to display in stack dumps. > > We should probably cleanse the 64-bit code of the remaining > "SYSENTER" nomenclature too at some point. > >

Re: [PATCH 16/21] x86/entry/64: Use a per-CPU trampoline stack for IDT entries

> From: Dave Hansen > > The "SYSENTER" stack is used for a lot more than SYSENTER now. > Give it a better string to display in stack dumps. > > We should probably cleanse the 64-bit code of the remaining > "SYSENTER" nomenclature too at some point. > > Signed-off-by: Dave Hansen > --- > >

4.14.0: built-in drivers now require built-in firmware?

The subject question is due to trouble encountered on a DEC Alpha getting the 4.14.0 kernel to see the machine's SCSI disks at boot time. I'm using the standard kernel source tree, and have long made it a practice to build-in the drivers for devices required at boot time (such as for the video

4.14.0: built-in drivers now require built-in firmware?

The subject question is due to trouble encountered on a DEC Alpha getting the 4.14.0 kernel to see the machine's SCSI disks at boot time. I'm using the standard kernel source tree, and have long made it a practice to build-in the drivers for devices required at boot time (such as for the video

Re: [PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

On Fri, Dec 01, 2017 at 10:23:25PM -0800, Nicolin Chen wrote: > The eukrea-tlv320 driver is still compiled successfully without > any erorr using imx_v6_v6_defconfig, after removing it. A typo here, should be imx_v6_v7_defconfig. Sending a v2 anyway. Please ignore this version. Thanks.

Re: [PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

On Fri, Dec 01, 2017 at 10:23:25PM -0800, Nicolin Chen wrote: > The eukrea-tlv320 driver is still compiled successfully without > any erorr using imx_v6_v6_defconfig, after removing it. A typo here, should be imx_v6_v7_defconfig. Sending a v2 anyway. Please ignore this version. Thanks.

[PATCH v2] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

The machine driver links both imx-ssi (legacy non-DT driver) and fsl_ssi (up-to-date DT based driver). So It also includes both imx-ssi.h and fsl_ssi.h header files. This creates a limitation for two header files -- they can't define anything with identical names. Since the eukrea-tlv320 machine

[PATCH v2] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

The machine driver links both imx-ssi (legacy non-DT driver) and fsl_ssi (up-to-date DT based driver). So It also includes both imx-ssi.h and fsl_ssi.h header files. This creates a limitation for two header files -- they can't define anything with identical names. Since the eukrea-tlv320 machine

Re: [PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

[PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h Please ignore the "9/9" in the tag...I forgot to clean it. It would be removed after getting applied though...

Re: [PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

[PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h Please ignore the "9/9" in the tag...I forgot to clean it. It would be removed after getting applied though...

[PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

The machine driver links both imx-ssi (legacy non-DT driver) and fsl_ssi (up-to-date DT based driver). So It also includes both imx-ssi.h and fsl_ssi.h header files. This creates a limitation for two header files -- they can't define anything with identical names. Since the eukrea-tlv320 machine

[PATCH 9/9] ASoC: eukrea-tlv320: Remove include line of fsl_ssi.h

The machine driver links both imx-ssi (legacy non-DT driver) and fsl_ssi (up-to-date DT based driver). So It also includes both imx-ssi.h and fsl_ssi.h header files. This creates a limitation for two header files -- they can't define anything with identical names. Since the eukrea-tlv320 machine

[PATCH 0/2] KPTI: get rid of cpu_entry_area mapping duplication

I like this variant much better. It might also fix the nasty bug tglx and peterz were chasing. Andy Lutomirski (2): Undo the split of setup_cpu_entry_area x86/kpti: Reference all cpu_entry_area pagetables in the usermode tables arch/x86/include/asm/fixmap.h | 14 +---

[PATCH 1/2] Undo the split of setup_cpu_entry_area

This is obviously a hack. Either the patch should be adjusted back to the version I sent or trap_init should forcibly initialize all PMDs by something like __set_fixmap(..., __mkpte(0)); or however it's spelled. --- arch/x86/kernel/smpboot.c | 2 ++ arch/x86/kernel/traps.c | 6 +- 2 files

[PATCH 0/2] KPTI: get rid of cpu_entry_area mapping duplication

I like this variant much better. It might also fix the nasty bug tglx and peterz were chasing. Andy Lutomirski (2): Undo the split of setup_cpu_entry_area x86/kpti: Reference all cpu_entry_area pagetables in the usermode tables arch/x86/include/asm/fixmap.h | 14 +---

[PATCH 1/2] Undo the split of setup_cpu_entry_area

This is obviously a hack. Either the patch should be adjusted back to the version I sent or trap_init should forcibly initialize all PMDs by something like __set_fixmap(..., __mkpte(0)); or however it's spelled. --- arch/x86/kernel/smpboot.c | 2 ++ arch/x86/kernel/traps.c | 6 +- 2 files

[PATCH 2/2] x86/kpti: Reference all cpu_entry_area pagetables in the usermode tables

We were manually configuring cpu_entry_area in the usermode tables. This was error-prone and wasted memory. (Not much memory, but still.) Instead, just reference the same pagetables. This avoids needing to keep the KPTI code and the normal cpu_entry_area code in sync, since the KPTI code no

[PATCH 2/2] x86/kpti: Reference all cpu_entry_area pagetables in the usermode tables

We were manually configuring cpu_entry_area in the usermode tables. This was error-prone and wasted memory. (Not much memory, but still.) Instead, just reference the same pagetables. This avoids needing to keep the KPTI code and the normal cpu_entry_area code in sync, since the KPTI code no

Re: [PATCH 2/2] ipc: Fix ipc data structures inconsistency

Hi, On 12/01/2017 06:20 PM, Davidlohr Bueso wrote: On Thu, 30 Nov 2017, Philippe Mikoyan wrote: As described in the title, this patch fixes id_ds inconsistency when ctl_stat runs concurrently with some ds-changing function, e.g. shmat, msgsnd or whatever. For instance, if shmctl(IPC_STAT) is

Re: [PATCH 2/2] ipc: Fix ipc data structures inconsistency

Hi, On 12/01/2017 06:20 PM, Davidlohr Bueso wrote: On Thu, 30 Nov 2017, Philippe Mikoyan wrote: As described in the title, this patch fixes id_ds inconsistency when ctl_stat runs concurrently with some ds-changing function, e.g. shmat, msgsnd or whatever. For instance, if shmctl(IPC_STAT) is

[PATCH v2] ubsan: don't handle misaligned address when support unaligned access

The ubsan always report Warning just like: UBSAN: Undefined behaviour in ../include/linux/etherdevice.h:386:9 load of misaligned address ffc069ba0482 for type 'long unsigned int' which requires 8 byte alignment CPU: 0 PID: 901 Comm: sshd Not tainted 4.xx+ #1 Hardware name: linux,dummy-virt

[PATCH v2] ubsan: don't handle misaligned address when support unaligned access

The ubsan always report Warning just like: UBSAN: Undefined behaviour in ../include/linux/etherdevice.h:386:9 load of misaligned address ffc069ba0482 for type 'long unsigned int' which requires 8 byte alignment CPU: 0 PID: 901 Comm: sshd Not tainted 4.xx+ #1 Hardware name: linux,dummy-virt

Re: [PATCH v5 10/12] perf util: Reuse thread_map__new_by_uid to enumerate threads from /proc

On 12/1/2017 11:02 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 11:44:25AM -0300, Arnaldo Carvalho de Melo escreveu: Em Fri, Dec 01, 2017 at 06:57:34PM +0800, Jin Yao escreveu: Perf already has a function thread_map__new_by_uid() which can enumerate all threads from /proc by

Re: [PATCH v5 10/12] perf util: Reuse thread_map__new_by_uid to enumerate threads from /proc

On 12/1/2017 11:02 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 11:44:25AM -0300, Arnaldo Carvalho de Melo escreveu: Em Fri, Dec 01, 2017 at 06:57:34PM +0800, Jin Yao escreveu: Perf already has a function thread_map__new_by_uid() which can enumerate all threads from /proc by

Re: [PATCH v5 10/12] perf util: Reuse thread_map__new_by_uid to enumerate threads from /proc

On 12/1/2017 10:44 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:34PM +0800, Jin Yao escreveu: Perf already has a function thread_map__new_by_uid() which can enumerate all threads from /proc by uid. This patch creates a static function enumerate_threads() which reuses the

Re: [PATCH v5 10/12] perf util: Reuse thread_map__new_by_uid to enumerate threads from /proc

On 12/1/2017 10:44 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:34PM +0800, Jin Yao escreveu: Perf already has a function thread_map__new_by_uid() which can enumerate all threads from /proc by uid. This patch creates a static function enumerate_threads() which reuses the

Re: [PATCH v5 06/12] perf util: Update and print per-thread shadow stats

On 12/1/2017 10:21 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:30PM +0800, Jin Yao escreveu: The functions perf_stat__update_shadow_stats() and perf_stat__print_shadow_statss() are called to update and print the shadow stats on a set of static variables. But the static

Re: [PATCH v5 06/12] perf util: Update and print per-thread shadow stats

On 12/1/2017 10:21 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:30PM +0800, Jin Yao escreveu: The functions perf_stat__update_shadow_stats() and perf_stat__print_shadow_statss() are called to update and print the shadow stats on a set of static variables. But the static

Re: [PATCH tip/core/rcu 20/21] checkpatch: Add warnings for {smp_,}read_barrier_depends()

On Fri, 2017-12-01 at 13:44 -0800, Paul E. McKenney wrote: > On Fri, Dec 01, 2017 at 12:14:17PM -0800, Joe Perches wrote: > > On Fri, 2017-12-01 at 11:51 -0800, Paul E. McKenney wrote: > > > Now that both smp_read_barrier_depends() and read_barrier_depends() > > > are being de-emphasized, warn if

Re: [PATCH tip/core/rcu 20/21] checkpatch: Add warnings for {smp_,}read_barrier_depends()

On Fri, 2017-12-01 at 13:44 -0800, Paul E. McKenney wrote: > On Fri, Dec 01, 2017 at 12:14:17PM -0800, Joe Perches wrote: > > On Fri, 2017-12-01 at 11:51 -0800, Paul E. McKenney wrote: > > > Now that both smp_read_barrier_depends() and read_barrier_depends() > > > are being de-emphasized, warn if

Re: [PATCH v5 03/12] perf util: Extend rbtree to support shadow stats

On 12/1/2017 10:10 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:27PM +0800, Jin Yao escreveu: Previously the rbtree was used to link generic metrics. Try to make the one line subject more descriptive, I'm changing it to: perf stat: Extend rbtree to support per-thread

Re: [PATCH v5 03/12] perf util: Extend rbtree to support shadow stats

On 12/1/2017 10:10 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:27PM +0800, Jin Yao escreveu: Previously the rbtree was used to link generic metrics. Try to make the one line subject more descriptive, I'm changing it to: perf stat: Extend rbtree to support per-thread

Re: [PATCH v5 02/12] perf util: Define a structure for runtime shadow stats

On 12/1/2017 10:02 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:26PM +0800, Jin Yao escreveu: Perf has a set of static variables to record the runtime shadow metrics stats. While if we want to record the runtime shadow stats for per-thread, it will be the limitation.

Re: [PATCH v5 02/12] perf util: Define a structure for runtime shadow stats

On 12/1/2017 10:02 PM, Arnaldo Carvalho de Melo wrote: Em Fri, Dec 01, 2017 at 06:57:26PM +0800, Jin Yao escreveu: Perf has a set of static variables to record the runtime shadow metrics stats. While if we want to record the runtime shadow stats for per-thread, it will be the limitation.

[PATCH V5 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW

A new version of the HIDMA IP has been released with bug fixes. Bumping the hardware version to differentiate from others. Signed-off-by: Sinan Kaya --- Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH V5 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW

A new version of the HIDMA IP has been released with bug fixes. Bumping the hardware version to differentiate from others. Signed-off-by: Sinan Kaya --- Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH V5 3/7] device property: Introduce a common API to fetch device match data

There is an OF/ACPI function to obtain the driver data. We want to hide OF/ACPI details from the device drivers and abstract following the device family of functions. Signed-off-by: Sinan Kaya --- drivers/base/property.c | 7 +++ include/linux/fwnode.h | 4

[PATCH V5 5/7] ACPI: properties: Implement get_match_data() callback

Now that we have a get_match_data() callback as part of the firmware node, implement the ACPI specific piece for it. Signed-off-by: Sinan Kaya --- drivers/acpi/property.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/acpi/property.c

[PATCH V5 3/7] device property: Introduce a common API to fetch device match data

There is an OF/ACPI function to obtain the driver data. We want to hide OF/ACPI details from the device drivers and abstract following the device family of functions. Signed-off-by: Sinan Kaya --- drivers/base/property.c | 7 +++ include/linux/fwnode.h | 4 include/linux/property.h

[PATCH V5 5/7] ACPI: properties: Implement get_match_data() callback

Now that we have a get_match_data() callback as part of the firmware node, implement the ACPI specific piece for it. Signed-off-by: Sinan Kaya --- drivers/acpi/property.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c index

[PATCH V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function

OF has of_device_get_match_data() function to extract driver specific data structure. Add a similar function for ACPI. Signed-off-by: Sinan Kaya --- drivers/acpi/bus.c | 13 + include/linux/acpi.h | 8 2 files changed, 21 insertions(+) diff --git

[PATCH V5 2/7] ACPI / bus: Introduce acpi_get_match_data() function

OF has of_device_get_match_data() function to extract driver specific data structure. Add a similar function for ACPI. Signed-off-by: Sinan Kaya --- drivers/acpi/bus.c | 13 + include/linux/acpi.h | 8 2 files changed, 21 insertions(+) diff --git a/drivers/acpi/bus.c

[PATCH V5 4/7] OF: properties: Implement get_match_data() callback

Now that we have a get_match_data() callback as part of the firmware node, implement the OF specific piece for it. Signed-off-by: Sinan Kaya --- drivers/of/property.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/of/property.c

[PATCH V5 4/7] OF: properties: Implement get_match_data() callback

Now that we have a get_match_data() callback as part of the firmware node, implement the OF specific piece for it. Signed-off-by: Sinan Kaya --- drivers/of/property.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/of/property.c b/drivers/of/property.c index

[PATCH V5 7/7] dmaengine: qcom_hidma: Add identity register support

The location for destination event channel register has been relocated from offset 0x28 to 0x40. Update the code accordingly. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git

[PATCH V5 6/7] dmaengine: qcom_hidma: Add support for the new revision

Add support for probing the newer HW and also organize MSI capable hardware into an array for maintenance reasons. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c | 34 +- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git

[PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

There is no real need for the users of timecounters to define cyclecounter and timecounter variables separately. Since timecounter will always be based on cyclecounter, have cyclecounter struct as member of timecounter struct. Suggested-by: Chris Wilson Signed-off-by:

[PATCH V5 7/7] dmaengine: qcom_hidma: Add identity register support

The location for destination event channel register has been relocated from offset 0x28 to 0x40. Update the code accordingly. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/dma/qcom/hidma.c

[PATCH V5 6/7] dmaengine: qcom_hidma: Add support for the new revision

Add support for probing the newer HW and also organize MSI capable hardware into an array for maintenance reasons. Signed-off-by: Sinan Kaya --- drivers/dma/qcom/hidma.c | 34 +- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git

[PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct

There is no real need for the users of timecounters to define cyclecounter and timecounter variables separately. Since timecounter will always be based on cyclecounter, have cyclecounter struct as member of timecounter struct. Suggested-by: Chris Wilson Signed-off-by: Sagar Arun Kamble Cc:

[PATCH] perf c2c: Add a tip about cacheline events

Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Sangwon Hong --- tools/perf/Documentation/tips.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/Documentation/tips.txt b/tools/perf/Documentation/tips.txt index

[PATCH] perf c2c: Add a tip about cacheline events

Cc: Jiri Olsa Cc: Namhyung Kim Signed-off-by: Sangwon Hong --- tools/perf/Documentation/tips.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/Documentation/tips.txt b/tools/perf/Documentation/tips.txt index 3dd1dbe..849599f 100644 --- a/tools/perf/Documentation/tips.txt +++

[PATCH] fix system_state checking in early_ioremap

Since below commit earlyprintk=efi,keep does not work any more with a warning in mm/early_ioremap.c: WARN_ON(system_state >= SYSTEM_RUNNING): commit 69a78ff226fe ("init: Introduce SYSTEM_SCHEDULING state") Reason is the the original assumption is SYSTEM_BOOTING equal to system_state <

[PATCH] fix system_state checking in early_ioremap

Since below commit earlyprintk=efi,keep does not work any more with a warning in mm/early_ioremap.c: WARN_ON(system_state >= SYSTEM_RUNNING): commit 69a78ff226fe ("init: Introduce SYSTEM_SCHEDULING state") Reason is the the original assumption is SYSTEM_BOOTING equal to system_state <

[PATCH net-next v2] net: dsa: Allow compiling out legacy support

Introduce a configuration option: CONFIG_NET_DSA_LEGACY allowing to compile out support for the old platform device and Device Tree binding registration. Support for these configurations is scheduled to be removed in 4.17. Signed-off-by: Florian Fainelli --- Changes in v2:

[PATCH net-next v2] net: dsa: Allow compiling out legacy support

Introduce a configuration option: CONFIG_NET_DSA_LEGACY allowing to compile out support for the old platform device and Device Tree binding registration. Support for these configurations is scheduled to be removed in 4.17. Signed-off-by: Florian Fainelli --- Changes in v2: - make the option

RISC-V Memory Consistency Model Draft Specification

I'm not sure what the best way to make sure this gets to all the right people is, so I've CC'd everyone I could find who contributed to our recent RISC-V related memory model discussions on LKML. Sorry if this ends up blowing up someone's inbox. Daniel Lustig, the chair of the RISC-V memory

RISC-V Memory Consistency Model Draft Specification

I'm not sure what the best way to make sure this gets to all the right people is, so I've CC'd everyone I could find who contributed to our recent RISC-V related memory model discussions on LKML. Sorry if this ends up blowing up someone's inbox. Daniel Lustig, the chair of the RISC-V memory

[PATCH v1 3/6] ARM: davinci: don't use static clk_lookup

In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. Each CPU family is given a new CPU-specific init_time function that

[PATCH v1 1/6] ARM: davinci: clean up map_io functions

This cleans up the map_io functions in the board init files for mach-davinci. Most of the boards had a wrapper function around _init(). This wrapper is removed and the function is used directly. Additionally, the _init() functions are renamed to _map_io() to match the field name. Signed-off-by:

[PATCH v1 3/6] ARM: davinci: don't use static clk_lookup

In preparation of moving to the common clock framework, usage of static struct clk_lookup is removed. The common clock framework uses an opaque struct clk, so we won't be able to use static tables as was previously done. Each CPU family is given a new CPU-specific init_time function that

[PATCH v1 1/6] ARM: davinci: clean up map_io functions

This cleans up the map_io functions in the board init files for mach-davinci. Most of the boards had a wrapper function around _init(). This wrapper is removed and the function is used directly. Additionally, the _init() functions are renamed to _map_io() to match the field name. Signed-off-by:

[PATCH v1 4/6] ARM: davinci: make davinci_clk_reset() static

This makes davinci_clk_reset() static. It is not used anywhere else. Signed-off-by: David Lechner --- arch/arm/mach-davinci/clock.c | 3 +-- arch/arm/mach-davinci/clock.h | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/clock.c

[PATCH v1 4/6] ARM: davinci: make davinci_clk_reset() static

This makes davinci_clk_reset() static. It is not used anywhere else. Signed-off-by: David Lechner --- arch/arm/mach-davinci/clock.c | 3 +-- arch/arm/mach-davinci/clock.h | 1 - 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/clock.c

[PATCH v1 6/6] ARM: davinci: remove clock debugfs

This removed the debugfs entry for mach-davinci clocks. The clocks now use the common clock framework, which provides debugfs already, so this code is redundant. Signed-off-by: David Lechner --- arch/arm/mach-davinci/clock.c | 79 ---

[PATCH v1 6/6] ARM: davinci: remove clock debugfs

This removed the debugfs entry for mach-davinci clocks. The clocks now use the common clock framework, which provides debugfs already, so this code is redundant. Signed-off-by: David Lechner --- arch/arm/mach-davinci/clock.c | 79 --- 1 file changed, 79

[PATCH v1 2/6] ARM: davinci: move davinci_clk_init() to init_time

This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. Signed-off-by: David Lechner --- arch/arm/mach-davinci/da830.c | 2 --

[PATCH v1 2/6] ARM: davinci: move davinci_clk_init() to init_time

This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. Signed-off-by: David Lechner --- arch/arm/mach-davinci/da830.c | 2 --

[PATCH v1 5/6] ARM: davinci: convert to common clock framework

This converts the clocks in mach-davinci to the common clock framework. Most of the patch just involves renaming struct clk to struct davinci_clk. There is also a struct clk_hw added to provide the bridge between the existing clock implementation and the common clock framework. In clock.c: *

[PATCH v1 5/6] ARM: davinci: convert to common clock framework

This converts the clocks in mach-davinci to the common clock framework. Most of the patch just involves renaming struct clk to struct davinci_clk. There is also a struct clk_hw added to provide the bridge between the existing clock implementation and the common clock framework. In clock.c: *

[PATCH v1 0/6] ARM: davinci: convert to common clock framework

This series takes the first steps towards moving mach-davinci to the common clock framework. Basically, this series does some cleanup and rearranging to get things ready for the conversion. Then in "ARM: davinci: convert to common clock framework" we actually make the conversion. This is done by

[PATCH v1 0/6] ARM: davinci: convert to common clock framework

This series takes the first steps towards moving mach-davinci to the common clock framework. Basically, this series does some cleanup and rearranging to get things ready for the conversion. Then in "ARM: davinci: convert to common clock framework" we actually make the conversion. This is done by

Re: [PATCH] compiler, clang: handle randomizable anonymous structs

On Thu, Nov 09, 2017 at 12:16:45PM +0530, Sandipan Das wrote: > The GCC randomize layout plugin can randomize the member > offsets of sensitive kernel data structures. To use this > feature, certain annotations and members are added to the > structures which affect the member offsets even if this

Re: [PATCH] compiler, clang: handle randomizable anonymous structs

On Thu, Nov 09, 2017 at 12:16:45PM +0530, Sandipan Das wrote: > The GCC randomize layout plugin can randomize the member > offsets of sensitive kernel data structures. To use this > feature, certain annotations and members are added to the > structures which affect the member offsets even if this

[PATCH] mmap.2: MAP_FIXED is no longer discouraged

From: John Hubbard MAP_FIXED has been widely used for a very long time, yet the man page still claims that "the use of this option is discouraged". The documentation assumes that "less portable" == "must be discouraged". Instead of discouraging something that is so useful

[PATCH] mmap.2: MAP_FIXED is no longer discouraged

From: John Hubbard MAP_FIXED has been widely used for a very long time, yet the man page still claims that "the use of this option is discouraged". The documentation assumes that "less portable" == "must be discouraged". Instead of discouraging something that is so useful and widely used,

Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

On Fri, 01 Dec 2017 16:47:16 PST (-0800), Linus Torvalds wrote: On Fri, Dec 1, 2017 at 4:39 PM, Palmer Dabbelt wrote: I've been maintaining the various cleanup patch sets I have as their own branches, which I then merged together and signed. Each merge commit has a short

Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

On Fri, 01 Dec 2017 16:47:16 PST (-0800), Linus Torvalds wrote: On Fri, Dec 1, 2017 at 4:39 PM, Palmer Dabbelt wrote: I've been maintaining the various cleanup patch sets I have as their own branches, which I then merged together and signed. Each merge commit has a short summary of the

[PATCH RT 0/9] Linux 4.4.102-rt117-rc1

Dear RT Folks, This is the RT stable review cycle of patch 4.4.102-rt117-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 0/9] Linux 4.4.102-rt117-rc1

Dear RT Folks, This is the RT stable review cycle of patch 4.4.102-rt117-rc1. Please scream at me if I messed something up. Please test the patches too. The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release

[PATCH RT 2/9] cpu_pm: replace raw_notifier to atomic_notifier

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Alex Shi This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu. The first to reason to have this replace is due

[PATCH RT 2/9] cpu_pm: replace raw_notifier to atomic_notifier

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Alex Shi This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu. The first to reason to have this replace is due to a 'scheduling

[PATCH RT 3/9] kernel/hrtimer: migrate deferred timer on CPU down

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior hrtimers, which were deferred to the softirq context, and expire between softirq shutdown and hrtimer migration are dangling

[PATCH v3] staging: xgifb: remove macros with hidden variable

This patch removes macros in XGI_main.h that contain a xgifb_info variable. These macros hurt readability by hiding said variable behind a define. It also uses a temporary variable to keep the replaced code from getting too long. Signed-off-by: Joshua Abraham ---

[PATCH RT 3/9] kernel/hrtimer: migrate deferred timer on CPU down

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior hrtimers, which were deferred to the softirq context, and expire between softirq shutdown and hrtimer migration are dangling around. If the CPU goes back

[PATCH v3] staging: xgifb: remove macros with hidden variable

This patch removes macros in XGI_main.h that contain a xgifb_info variable. These macros hurt readability by hiding said variable behind a define. It also uses a temporary variable to keep the replaced code from getting too long. Signed-off-by: Joshua Abraham ---

[PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior This reverts commit "fs: jbd2: pull your plug when waiting for space". This was a duct-tape fix which shouldn't be needed since

[PATCH RT 4/9] kernel/hrtimer: dont wakeup a process while holding the hrtimer base lock

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior We must not wake any process (and thus acquire the pi->lock) while holding the hrtimer's base lock. This does not happen usually

[PATCH RT 5/9] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer

[PATCH RT 4/9] kernel/hrtimer: dont wakeup a process while holding the hrtimer base lock

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior We must not wake any process (and thus acquire the pi->lock) while holding the hrtimer's base lock. This does not happen usually because the

[PATCH RT 5/9] kernel/hrtimer/hotplug: dont wake ktimersoftd while holding the hrtimer base lock

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Mike Galbraith kernel/hrtimer: don't wakeup a process while holding the hrtimer base lock missed a path, namely hrtimers_dead_cpu() -> migrate_hrtimer_list(). Defer raising

[PATCH RT 1/9] Revert "fs: jbd2: pull your plug when waiting for space"

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior This reverts commit "fs: jbd2: pull your plug when waiting for space". This was a duct-tape fix which shouldn't be needed since commit "locking/rt-mutex:

[PATCH RT 8/9] net: use trylock in icmp_sk

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The locking path can be recursive (same as for sk->sk_lock.slock) and therefore we need a trylock version for the locallock, too.

[PATCH RT 8/9] net: use trylock in icmp_sk

4.4.102-rt117-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Sebastian Andrzej Siewior The locking path can be recursive (same as for sk->sk_lock.slock) and therefore we need a trylock version for the locallock, too. Cc:

  1   2   3   4   5   6   7   8   9   10   >