Re: Bricked x86 CPU with software?

> Hi! > > On Thu 2018-01-04 17:21:36, Tim Mouraveiko wrote: > > > On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote: > > > > > > As I mentioned before, I repeatedly and fully power-cycled the > > > > > > motherboard and reset BIOS > > > > > > and etc. It made no difference. I can see that the

Re: Bricked x86 CPU with software?

> Hi! > > On Thu 2018-01-04 17:21:36, Tim Mouraveiko wrote: > > > On Thu 2018-01-04 14:13:56, Tim Mouraveiko wrote: > > > > > > As I mentioned before, I repeatedly and fully power-cycled the > > > > > > motherboard and reset BIOS > > > > > > and etc. It made no difference. I can see that the

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

Hi Baoquan, thank you very much for your review! On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it > > > will ignore the ram we need dump. > > > > yes, instead of crashing the machine (because GART may be

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

Hi Baoquan, thank you very much for your review! On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it > > > will ignore the ram we need dump. > > > > yes, instead of crashing the machine (because GART may be

Re: Bricked x86 CPU with software?

> On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko wrote: > > Pavel, > > > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > > and reset BIOS > > and etc. It made no difference. I can see that the processor was not > > drawing any power. The > >

Re: Bricked x86 CPU with software?

> On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko wrote: > > Pavel, > > > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > > and reset BIOS > > and etc. It made no difference. I can see that the processor was not > > drawing any power. The > > software code behaved

[PATCH 0/2] fix kernel-docs for struct iio_trigger

This set is a re-spin of [PATCH] iio: add kernel-doc '@owner' Patch 1 is the original patch. Adds a kernel-doc description for field @owner clearing a sphinx build warning when building kernel documentation. Patch 2 adds field identifier for @use_count. Currently this field has a

[PATCH 0/2] fix kernel-docs for struct iio_trigger

This set is a re-spin of [PATCH] iio: add kernel-doc '@owner' Patch 1 is the original patch. Adds a kernel-doc description for field @owner clearing a sphinx build warning when building kernel documentation. Patch 2 adds field identifier for @use_count. Currently this field has a

Re: [PATCH] ARM64: dts: meson-gxl: add internal ethernet PHY irq

Jerome Brunet writes: > Add the interrupt of the internal ethernet PHY > > Signed-off-by: Jerome Brunet > --- > Hi Kevin, > > This changes depends on the net-next changes adding interrupt support [0]. > It is really important that this change is not

Re: [PATCH] ARM64: dts: meson-gxl: add internal ethernet PHY irq

Jerome Brunet writes: > Add the interrupt of the internal ethernet PHY > > Signed-off-by: Jerome Brunet > --- > Hi Kevin, > > This changes depends on the net-next changes adding interrupt support [0]. > It is really important that this change is not merged before its > dependency. > > If it is

[PATCH 2/3] ARM: tegra: paz00: drop nonstandard 'backlight-boot-off'

This was used out-of-tree as a hack for resolving issues where some systems expect the backlight to turn on automatically at boot, while others expect to manage the backlight status via a DRM/panel driver. Those issues have since been fixed upstream in pwm_bl.c without device tree hacks, and so

[PATCH 2/3] ARM: tegra: paz00: drop nonstandard 'backlight-boot-off'

This was used out-of-tree as a hack for resolving issues where some systems expect the backlight to turn on automatically at boot, while others expect to manage the backlight status via a DRM/panel driver. Those issues have since been fixed upstream in pwm_bl.c without device tree hacks, and so

[PATCH 3/3] arm64: tegra: remove tegra132 norrin's nonstandard 'backlight-boot-off'

This was used out-of-tree as a hack for resolving issues where some systems expect the backlight to turn on automatically at boot, while others expect to manage the backlight status via a DRM/panel driver. Those issues have since been fixed upstream in pwm_bl.c without device tree hacks, and so

[PATCH 1/3] ARM: dts: rockchip: drop veyron's nonstandard 'backlight-boot-off'

This was used out-of-tree as a hack for resolving issues where some systems expect the backlight to turn on automatically at boot, while others expect to manage the backlight status via a DRM/panel driver. Those issues have since been fixed upstream in pwm_bl.c without device tree hacks, and so

[PATCH 3/3] arm64: tegra: remove tegra132 norrin's nonstandard 'backlight-boot-off'

This was used out-of-tree as a hack for resolving issues where some systems expect the backlight to turn on automatically at boot, while others expect to manage the backlight status via a DRM/panel driver. Those issues have since been fixed upstream in pwm_bl.c without device tree hacks, and so

[PATCH 1/3] ARM: dts: rockchip: drop veyron's nonstandard 'backlight-boot-off'

This was used out-of-tree as a hack for resolving issues where some systems expect the backlight to turn on automatically at boot, while others expect to manage the backlight status via a DRM/panel driver. Those issues have since been fixed upstream in pwm_bl.c without device tree hacks, and so

[PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

This takes care of 2 TODOs in this driver, by using the common DSI packet-marshalling code instead of our custom short/long write code. This both saves us some duplicated code and gets us free support for command types that weren't already part of our switch block (e.g.,

[PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

This takes care of 2 TODOs in this driver, by using the common DSI packet-marshalling code instead of our custom short/long write code. This both saves us some duplicated code and gets us free support for command types that weren't already part of our switch block (e.g.,

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 11:08:06AM -0600, Josh Poimboeuf wrote: > I seem to recall that we also discussed the need for this for converting > pvops to use alternatives, though the "why" is eluding me at the moment. Ok, here's something which seems to work in my VM here. I'll continue playing with

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 05, 2018 at 11:08:06AM -0600, Josh Poimboeuf wrote: > I seem to recall that we also discussed the need for this for converting > pvops to use alternatives, though the "why" is eluding me at the moment. Ok, here's something which seems to work in my VM here. I'll continue playing with

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

> >From an IIO sensor point of view A Gesture sensor: > Outputs > A pre defined activity type > WAKE > TILT > GLANCE > PICK_UP >  & >  more > > A user defined activity type as "string" > > Inputs >

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

> >From an IIO sensor point of view A Gesture sensor: > Outputs > A pre defined activity type > WAKE > TILT > GLANCE > PICK_UP >  & >  more > > A user defined activity type as "string" > > Inputs >

[PATCH] xtensa: fix futex_atomic_cmpxchg_inatomic

Return 0 if the operation was successful, not the userspace memory value. Check that userspace value equals passed oldval, not itself. Don't update *uval if the value wasn't read from userspace memory. This fixes process hang due to infinite loop in futex_lock_pi. It also fixes a bunch of glibc

[PATCH] xtensa: fix futex_atomic_cmpxchg_inatomic

Return 0 if the operation was successful, not the userspace memory value. Check that userspace value equals passed oldval, not itself. Don't update *uval if the value wasn't read from userspace memory. This fixes process hang due to infinite loop in futex_lock_pi. It also fixes a bunch of glibc

[PATCH v2 1/5] ARM64: dts: meson: uart: fix address space range

The address space range is actually 0x18, fixed here. Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++-- arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description

Describe the pinctrl info for the UART controller which is found in the Meson-AXG SoCs. Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++ 1 file changed, 97 insertions(+) diff --git

Re: [PATCH] leaking_addresses: add files to skip

On Fri, Jan 5, 2018 at 2:59 PM, Tobin C. Harding wrote: > Script currently times out when parsing the following files: > > /proc/kallsyms > /proc/sched_debug > /proc/PID/smaps Seems like kallsyms would be one to absolutely scan... it shouldn't cause hangs

[PATCH v2 5/5] ARM64: dts: meson-axg: enable the UART_A controller

The UART_A is connected to a BT module on the S400 board. Acked-by: Jerome Brunet Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [PATCH] leaking_addresses: add files to skip

On Fri, Jan 5, 2018 at 2:59 PM, Tobin C. Harding wrote: > Script currently times out when parsing the following files: > > /proc/kallsyms > /proc/sched_debug > /proc/PID/smaps Seems like kallsyms would be one to absolutely scan... it shouldn't cause hangs either. -Kees

[PATCH v2 5/5] ARM64: dts: meson-axg: enable the UART_A controller

The UART_A is connected to a BT module on the S400 board. Acked-by: Jerome Brunet Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts

[PATCH v2 1/5] ARM64: dts: meson: uart: fix address space range

The address space range is actually 0x18, fixed here. Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++-- arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v2 3/5] ARM64: dts: meson-axg: uart: Add the pinctrl info description

Describe the pinctrl info for the UART controller which is found in the Meson-AXG SoCs. Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 97 ++ 1 file changed, 97 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi

[PATCH v2 0/5] ARM64: dts: meson-axg: UART DT updates

HI Kevin These are the UART DT updates for the Meson-AXG platform. The patch 1 is a general fix. Other patches are about adding clock & pinctrl info, then using them. Last patch enable UART_A which connect to a BT module on the S400 board. Note: This series depend on previous UART_AO clock

[PATCH v2 0/5] ARM64: dts: meson-axg: UART DT updates

HI Kevin These are the UART DT updates for the Meson-AXG platform. The patch 1 is a general fix. Other patches are about adding clock & pinctrl info, then using them. Last patch enable UART_A which connect to a BT module on the S400 board. Note: This series depend on previous UART_AO clock

[PATCH v2 4/5] ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A

Explictly request the pinctrl info for the UART_AO_A controller, otherwise we may need to rely on bootloader for the initialization. Acked-by: Jerome Brunet Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++ 1 file

[PATCH v2 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART

When update the clock info for the UART controller in the EE domain, the driver explicitly require 'pclk' in order to work properly. With current logic of the code, the driver will go for the legacy clock probe routine[1] if it find current compatible string match to 'amlogic,meson-uart', which

[PATCH v2 4/5] ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A

Explictly request the pinctrl info for the UART_AO_A controller, otherwise we may need to rely on bootloader for the initialization. Acked-by: Jerome Brunet Signed-off-by: Yixun Lan --- arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v2 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART

When update the clock info for the UART controller in the EE domain, the driver explicitly require 'pclk' in order to work properly. With current logic of the code, the driver will go for the legacy clock probe routine[1] if it find current compatible string match to 'amlogic,meson-uart', which

[PATCH v3] pinctrl: Add Microsemi Ocelot SoC driver

The Microsemi Ocelot SoC has a few pins that can be used as GPIOs or take multiple other functions. Add a driver for the pinmuxing and the GPIOs. There is currently no support for interrupts. Signed-off-by: Alexandre Belloni --- - use

[PATCH v3] pinctrl: Add Microsemi Ocelot SoC driver

The Microsemi Ocelot SoC has a few pins that can be used as GPIOs or take multiple other functions. Add a driver for the pinmuxing and the GPIOs. There is currently no support for interrupts. Signed-off-by: Alexandre Belloni --- - use pinctrl_gpio_direction_input/output from

[PATCH v3 1/4] remoteproc: Add remote processor coredump support

From: Sarangdhar Joshi As the remoteproc framework restarts the remote processor after a fatal event, it's useful to be able to acquire a coredump of the remote processor's state, for post mortem debugging. This patch introduces a mechanism for extracting the memory

[PATCH v3 0/4] Remoteproc core dump support

Picking up Sarangdhar's original patches for adding core dump support to remoteproc. Based on the recently proposed "load resources" hook this registers segments of the Qualcomm MDT file as dump segments which are used to build an ELF file representing the various memory segments in the case of a

[PATCH v3 3/4] soc: qcom: mdt-loader: Return relocation base

In order to implement support for grabbing core dumps in remoteproc it's necessary to know the relocated base of the image, as the offsets from the virtual memory base might not be based on the physical address. Return the adjusted physical base address to the caller. Signed-off-by: Bjorn

[PATCH v3 3/4] soc: qcom: mdt-loader: Return relocation base

In order to implement support for grabbing core dumps in remoteproc it's necessary to know the relocated base of the image, as the offsets from the virtual memory base might not be based on the physical address. Return the adjusted physical base address to the caller. Signed-off-by: Bjorn

[PATCH v3 1/4] remoteproc: Add remote processor coredump support

From: Sarangdhar Joshi As the remoteproc framework restarts the remote processor after a fatal event, it's useful to be able to acquire a coredump of the remote processor's state, for post mortem debugging. This patch introduces a mechanism for extracting the memory contents after the remote

[PATCH v3 0/4] Remoteproc core dump support

Picking up Sarangdhar's original patches for adding core dump support to remoteproc. Based on the recently proposed "load resources" hook this registers segments of the Qualcomm MDT file as dump segments which are used to build an ELF file representing the various memory segments in the case of a

[RFP] iio: Support of gesture sensor as a standard IIO sensor

Hi Jonathan and Everyone, The Intel Integrated sensor hub (ISH) on some platforms have ability to identify gestures. This is available on some Android platforms. We want to bring in this capability to other Linux flavors also.  This algorithm for gesture recognition executes in ISH as this is a

[PATCH v3 4/4] remoteproc: qcom: Register segments for core dump

From: Sarangdhar Joshi Register MDT segments with the remoteproc core dump functionality in order to include them in a core dump, in case of a recovery of the remote processor. Signed-off-by: Sarangdhar Joshi Signed-off-by: Bjorn Andersson

[PATCH v3 2/4] remoteproc: Rename "load_rsc_table" to "parse_fw"

The resource table is just one possible source of information that can be extracted from the firmware file. Generalize this interface to allow drivers to override this with parsers of other types of information. Signed-off-by: Bjorn Andersson --- Changes since v2: -

[PATCH v3 4/4] remoteproc: qcom: Register segments for core dump

From: Sarangdhar Joshi Register MDT segments with the remoteproc core dump functionality in order to include them in a core dump, in case of a recovery of the remote processor. Signed-off-by: Sarangdhar Joshi Signed-off-by: Bjorn Andersson --- Changes since v2: - None Changes since v1: -

[PATCH v3 2/4] remoteproc: Rename "load_rsc_table" to "parse_fw"

The resource table is just one possible source of information that can be extracted from the firmware file. Generalize this interface to allow drivers to override this with parsers of other types of information. Signed-off-by: Bjorn Andersson --- Changes since v2: - Improved comment by call to

[RFP] iio: Support of gesture sensor as a standard IIO sensor

Hi Jonathan and Everyone, The Intel Integrated sensor hub (ISH) on some platforms have ability to identify gestures. This is available on some Android platforms. We want to bring in this capability to other Linux flavors also.  This algorithm for gesture recognition executes in ISH as this is a

[PATCH] f2fs: allow quota to use reserved blocks

This patch allows quota to use reserved blocks all the time. Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index e5554b851fd8..827549077b81 100644 ---

[PATCH] f2fs: allow quota to use reserved blocks

This patch allows quota to use reserved blocks all the time. Signed-off-by: Jaegeuk Kim --- fs/f2fs/f2fs.h | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index e5554b851fd8..827549077b81 100644 --- a/fs/f2fs/f2fs.h +++

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen wrote: > > After v4.14, I've been unable to boot my AMD compilation box with the > v4.15-rc mainline Linux. It just ends up in a silent reboot loop. > > I bisected this to: > > commit fa564ad9636651fd11ec2c79c48dee844066f73a >

Re: [BISECTED] v4.15-rc: Boot regression on x86_64/AMD

On Fri, Jan 5, 2018 at 2:04 PM, Aaro Koskinen wrote: > > After v4.14, I've been unable to boot my AMD compilation box with the > v4.15-rc mainline Linux. It just ends up in a silent reboot loop. > > I bisected this to: > > commit fa564ad9636651fd11ec2c79c48dee844066f73a > Author: Christian König

[PATCH v2 1/8] remoteproc: Remove depricated crash completion

The crash handling now happens in a single execution context, so there's no longer a need for a completion to synchronize this. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/remoteproc_core.c | 10 --

[PATCH v2 1/8] remoteproc: Remove depricated crash completion

The crash handling now happens in a single execution context, so there's no longer a need for a completion to synchronize this. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/remoteproc_core.c | 10 -- include/linux/remoteproc.h | 2 -- 2

[PATCH v2 5/8] remoteproc: Don't handle empty resource table

Allow a NULL table_ptr to have the same meaning as a table with 0 entries, allowing a subsequent patch to skip the assignment step. A few other places in the implementation does dereference table_ptr, but they are currently all coming from rproc_handle_resources(). Signed-off-by: Bjorn Andersson

[PATCH v2 0/8] Remoteproc cleanups

The first patch removes code that became unnecessary when the recovery flow was redesigned. The following patches moves the assignment of cached_table to the resource table loader, rather than core code, which allows this to made optional and finally drops the various dummy resource tables

[PATCH v2 3/8] remoteproc: Clone rproc_ops in rproc_alloc()

In order to allow rproc_alloc() to, in a future patch, update entries in the "ops" struct we need to make a local copy of it. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/remoteproc_core.c | 9 - include/linux/remoteproc.h

[PATCH v2 5/8] remoteproc: Don't handle empty resource table

Allow a NULL table_ptr to have the same meaning as a table with 0 entries, allowing a subsequent patch to skip the assignment step. A few other places in the implementation does dereference table_ptr, but they are currently all coming from rproc_handle_resources(). Signed-off-by: Bjorn Andersson

[PATCH v2 0/8] Remoteproc cleanups

The first patch removes code that became unnecessary when the recovery flow was redesigned. The following patches moves the assignment of cached_table to the resource table loader, rather than core code, which allows this to made optional and finally drops the various dummy resource tables

[PATCH v2 3/8] remoteproc: Clone rproc_ops in rproc_alloc()

In order to allow rproc_alloc() to, in a future patch, update entries in the "ops" struct we need to make a local copy of it. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/remoteproc_core.c | 9 - include/linux/remoteproc.h | 2 +- 2 files

[PATCH v2 8/8] remoteproc: Reset table_ptr on stop

The installed resource table is no longer accessible after stopping the remote, so update table_ptr to point to the local copy. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/remoteproc_core.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH v2 7/8] remoteproc: Drop dangling find_rsc_table dummies

As the core now deals with the lack of a resource table, remove the dangling custom dummy implementations of find_rsc_table from drivers. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/qcom_adsp_pil.c | 1 -

[PATCH v2 8/8] remoteproc: Reset table_ptr on stop

The installed resource table is no longer accessible after stopping the remote, so update table_ptr to point to the local copy. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/remoteproc_core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v2 7/8] remoteproc: Drop dangling find_rsc_table dummies

As the core now deals with the lack of a resource table, remove the dangling custom dummy implementations of find_rsc_table from drivers. Signed-off-by: Bjorn Andersson --- Changes since v1: - None drivers/remoteproc/qcom_adsp_pil.c | 1 - drivers/remoteproc/qcom_common.c | 19

[PATCH v2 6/8] remoteproc: Move resource table load logic to find

Extend the previous operation of finding the resource table in the ELF with the extra step of populating the rproc struct with a copy and the size. This allows drivers to override the mechanism used for acquiring the resource table, or omit it for firmware that is known not to have a resource

[PATCH v2 6/8] remoteproc: Move resource table load logic to find

Extend the previous operation of finding the resource table in the ELF with the extra step of populating the rproc struct with a copy and the size. This allows drivers to override the mechanism used for acquiring the resource table, or omit it for firmware that is known not to have a resource

[PATCH v2 4/8] remoteproc: Merge rproc_ops and rproc_fw_ops

There are currently a few different schemes used for overriding fw_ops or parts of fw_ops. Merge fw_ops into rproc_ops and expose the default ELF-loader symbols so that they can be assigned by the drivers. To keep backwards compatibility with the "default" case, a driver not specifying the "load"

[PATCH v2 4/8] remoteproc: Merge rproc_ops and rproc_fw_ops

There are currently a few different schemes used for overriding fw_ops or parts of fw_ops. Merge fw_ops into rproc_ops and expose the default ELF-loader symbols so that they can be assigned by the drivers. To keep backwards compatibility with the "default" case, a driver not specifying the "load"

[PATCH v2 2/8] remoteproc: Cache resource table size

We don't re-read the resource table during a recovery, so it is possible in the recovery path that the resource table has a different size than cached_table. Store the original size of cached_table to avoid these getting out of sync. Signed-off-by: Bjorn Andersson ---

[PATCH v2 2/8] remoteproc: Cache resource table size

We don't re-read the resource table during a recovery, so it is possible in the recovery path that the resource table has a different size than cached_table. Store the original size of cached_table to avoid these getting out of sync. Signed-off-by: Bjorn Andersson --- Changes since v1: - None

[git pull] Input updates for v4.15-rc6

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a few driver fixups, nothing exciting. Changelog: - Aaron Ma (1): Input: elantech - add new icbody type 15 Anthony Kim

[git pull] Input updates for v4.15-rc6

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a few driver fixups, nothing exciting. Changelog: - Aaron Ma (1): Input: elantech - add new icbody type 15 Anthony Kim

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 5, 2018 at 2:00 PM, Woodhouse, David wrote: > +.macro RETPOLINE_JMP reg:req > + call1112f > +: lfence > + jmp b > +1112: mov %\reg, (%_ASM_SP) > + ret > +.endm > + > +.macro RETPOLINE_CALL reg:req > + jmp 1113f >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Fri, Jan 5, 2018 at 2:00 PM, Woodhouse, David wrote: > +.macro RETPOLINE_JMP reg:req > + call1112f > +: lfence > + jmp b > +1112: mov %\reg, (%_ASM_SP) > + ret > +.endm > + > +.macro RETPOLINE_CALL reg:req > + jmp 1113f > +1110: RETPOLINE_JMP

Re: [PATCH v2 5/6] clocksource: Add a new timer-ingenic driver

Hi Rob, Le sam. 6 janv. 2018 à 0:27, Rob Herring a écrit : On Wed, Jan 3, 2018 at 3:56 PM, Paul Cercueil wrote: Hi, Le mer. 3 janv. 2018 à 22:08, Rob Herring a écrit : On Mon, Jan 01, 2018 at 03:33:43PM +0100, Paul Cercueil

Re: [PATCH v2 5/6] clocksource: Add a new timer-ingenic driver

Hi Rob, Le sam. 6 janv. 2018 à 0:27, Rob Herring a écrit : On Wed, Jan 3, 2018 at 3:56 PM, Paul Cercueil wrote: Hi, Le mer. 3 janv. 2018 à 22:08, Rob Herring a écrit : On Mon, Jan 01, 2018 at 03:33:43PM +0100, Paul Cercueil wrote: This driver will use the TCU (Timer Counter Unit)

[PATCH v5] gpio: winbond: add driver

This commit adds GPIO driver for Winbond Super I/Os. Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is supported but in the future a support for other Winbond models, too, can be added to the driver. A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is

[PATCH v5] gpio: winbond: add driver

This commit adds GPIO driver for Winbond Super I/Os. Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is supported but in the future a support for other Winbond models, too, can be added to the driver. A module parameter "gpios" sets a bitmask of GPIO ports to enable (bit 0 is

Re: [PATCH] tools/power/x86/intel_pstate_tracer: Free the trace buffer memory

On Fri, 2018-01-05 at 23:54 +0100, Rafael J. Wysocki wrote: > On Fri, Jan 5, 2018 at 11:31 PM, Doug Smythies om> wrote: > > > > The trace buffer memory should be, mostly, freed after > > the buffer has been output. > > > > This patch is required before a future patch

Re: [PATCH v2 05/13] pinctrl: Add Microsemi Ocelot SoC driver

On 13/12/2017 at 09:15:20 +0100, Linus Walleij wrote: > You need to add some comment on what is happening here and how the > bits are used because just reading these two lines is pretty hard. > > I guess f = 0, 1, 2 31 or so. > > pin->pin is also 0, 1, 2 ... 31? > > BIT(pin->pin) is pretty

Re: [PATCH] tools/power/x86/intel_pstate_tracer: Free the trace buffer memory

On Fri, 2018-01-05 at 23:54 +0100, Rafael J. Wysocki wrote: > On Fri, Jan 5, 2018 at 11:31 PM, Doug Smythies om> wrote: > > > > The trace buffer memory should be, mostly, freed after > > the buffer has been output. > > > > This patch is required before a future patch that will allow > > the

Re: [PATCH v2 05/13] pinctrl: Add Microsemi Ocelot SoC driver

On 13/12/2017 at 09:15:20 +0100, Linus Walleij wrote: > You need to add some comment on what is happening here and how the > bits are used because just reading these two lines is pretty hard. > > I guess f = 0, 1, 2 31 or so. > > pin->pin is also 0, 1, 2 ... 31? > > BIT(pin->pin) is pretty

Re: [PATCH v4] gpio: winbond: add driver

On 05.01.2018 14:35, Andy Shevchenko wrote: > On Thu, 2018-01-04 at 22:46 +0100, Maciej S. Szmigiero wrote: >> This commit adds GPIO driver for Winbond Super I/Os. >> >> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is >> supported but in the future a support for other Winbond

Re: [PATCH v4] gpio: winbond: add driver

On 05.01.2018 14:35, Andy Shevchenko wrote: > On Thu, 2018-01-04 at 22:46 +0100, Maciej S. Szmigiero wrote: >> This commit adds GPIO driver for Winbond Super I/Os. >> >> Currently, only W83627UHG model (also known as Nuvoton NCT6627UD) is >> supported but in the future a support for other Winbond

[PATCH 2/2] RISC-V: Remove mem_end command line processing

This is just some cruft left over from before the port converted to device tree. The right way to handle memory regions is to specify them in the device tree, which BBL (our simplest bootloader) is already capable of doing. This patch simply removes the cruft. Signed-off-by: Palmer Dabbelt

[PATCH 2/2] RISC-V: Remove mem_end command line processing

This is just some cruft left over from before the port converted to device tree. The right way to handle memory regions is to specify them in the device tree, which BBL (our simplest bootloader) is already capable of doing. This patch simply removes the cruft. Signed-off-by: Palmer Dabbelt ---

[PATCH 1/2] RISC-V: Remove duplicate command-line parsing logic

From: Michael Clark builtin_cmdline handling is present in drivers/of/fdt.c so the duplicate logic in arch/riscv/setup.c results in duplication of the builtin command line. e.g. CONFIG_CMDLINE="root=/dev/vda ro" gets appended twice and gives "root=/dev/vda ro root=/dev/vda ro"

[PATCH 1/2] RISC-V: Remove duplicate command-line parsing logic

From: Michael Clark builtin_cmdline handling is present in drivers/of/fdt.c so the duplicate logic in arch/riscv/setup.c results in duplication of the builtin command line. e.g. CONFIG_CMDLINE="root=/dev/vda ro" gets appended twice and gives "root=/dev/vda ro root=/dev/vda ro" Before this

[ANNOUNCE] Git v2.16.0-rc1

A release candidate Git v2.16.0-rc1 is now available for testing at the usual places. It is comprised of 455 non-merge commits since v2.15.0, contributed by 79 people, 23 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

[ANNOUNCE] Git v2.16.0-rc1

A release candidate Git v2.16.0-rc1 is now available for testing at the usual places. It is comprised of 455 non-merge commits since v2.15.0, contributed by 79 people, 23 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH] ACPI / WMI: Call acpi_wmi_init() later

On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Calling acpi_wmi_init() at the subsys_initcall() level causes ordering > issues to appear on some systems and they are difficult to reproduce, > because there

Re: [PATCH] ACPI / WMI: Call acpi_wmi_init() later

On Wed, Jan 3, 2018 at 12:49 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Calling acpi_wmi_init() at the subsys_initcall() level causes ordering > issues to appear on some systems and they are difficult to reproduce, > because there is no guaranteed ordering between

Re: [PATCH v2 5/6] clocksource: Add a new timer-ingenic driver

On Wed, Jan 3, 2018 at 3:56 PM, Paul Cercueil wrote: > Hi, > > Le mer. 3 janv. 2018 à 22:08, Rob Herring a écrit : >> >> On Mon, Jan 01, 2018 at 03:33:43PM +0100, Paul Cercueil wrote: >>> >>> This driver will use the TCU (Timer Counter Unit) present on the

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 6:03 AM, Mike Galbraith wrote: > On Fri, 2018-01-05 at 14:34 +0100, Greg Kroah-Hartman wrote: >> >> Ok, we found two patches that were missing in 4.4-stable that were in >> the SLES12 tree (thanks to Jamie Iles), now I only have 19k more to sift >> through :)

Re: [PATCH v2 5/6] clocksource: Add a new timer-ingenic driver

On Wed, Jan 3, 2018 at 3:56 PM, Paul Cercueil wrote: > Hi, > > Le mer. 3 janv. 2018 à 22:08, Rob Herring a écrit : >> >> On Mon, Jan 01, 2018 at 03:33:43PM +0100, Paul Cercueil wrote: >>> >>> This driver will use the TCU (Timer Counter Unit) present on the Ingenic >>> JZ47xx SoCs to provide

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 5, 2018 at 6:03 AM, Mike Galbraith wrote: > On Fri, 2018-01-05 at 14:34 +0100, Greg Kroah-Hartman wrote: >> >> Ok, we found two patches that were missing in 4.4-stable that were in >> the SLES12 tree (thanks to Jamie Iles), now I only have 19k more to sift >> through :) > > As you

<    1   2   3   4   5   6   7   8   9   10   >