Re: [PATCH v2 13/17] iio: magnetometer: mag3110: Add OF device ID table

On 15/03/17 04:45, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 12/17] iio: adc: ti-ads1015: Add OF device ID table

On 15/03/17 04:45, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 11/17] iio: dac: max5821: Set .of_match_table to OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver has a OF device ID table but the struct i2c_driver > .of_match_table field is not set. > > Signed-off-by: Javier Martinez Canillas applied. > --- > > drivers/iio/dac/max5821.c | 1 + > 1 file changed, 1

Re: [PATCH v2 11/17] iio: dac: max5821: Set .of_match_table to OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver has a OF device ID table but the struct i2c_driver > .of_match_table field is not set. > > Signed-off-by: Javier Martinez Canillas applied. > --- > > drivers/iio/dac/max5821.c | 1 + > 1 file changed, 1 insertion(+) > > diff

Re: [PATCH v2 06/17] iio: light: tsl2563: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 06/17] iio: light: tsl2563: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 07/17] iio: pressure: hp03: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 07/17] iio: pressure: hp03: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 05/17] iio: light: us5182d: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 05/17] iio: light: us5182d: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [RESEND PATCH 2/7] time: Change posix clocks ops interfaces to use timespec64

On Sat, 18 Mar 2017, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Replace the posix_clock ops interfaces to use > struct timespec64. > The patch also changes struct itimerspec interfaces to > struct itimerspec64 as itimerspec internally uses timespec > and itimerspec64 uses

Re: [RESEND PATCH 2/7] time: Change posix clocks ops interfaces to use timespec64

On Sat, 18 Mar 2017, Deepa Dinamani wrote: > struct timespec is not y2038 safe. > Replace the posix_clock ops interfaces to use > struct timespec64. > The patch also changes struct itimerspec interfaces to > struct itimerspec64 as itimerspec internally uses timespec > and itimerspec64 uses

Re: [PATCH v2 04/17] iio: dac: mcp4725: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 04/17] iio: dac: mcp4725: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 03/17] iio: magnetometer: bmc150_magn_i2c: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 02/17] iio: mlx96014: Add OF device ID table

On 15/03/17 10:46, Crt Mori wrote: > Hi, > Thanks for the patch. If the assumption will not be there than this > fix is needed. I tested it on BeagleBoneBlack and it does not effect > anything. > > Tested-by: Crt Mori > Acked-by: Crt Mori Applied. Thanks,

Re: [PATCH v2 03/17] iio: magnetometer: bmc150_magn_i2c: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 02/17] iio: mlx96014: Add OF device ID table

On 15/03/17 10:46, Crt Mori wrote: > Hi, > Thanks for the patch. If the assumption will not be there than this > fix is needed. I tested it on BeagleBoneBlack and it does not effect > anything. > > Tested-by: Crt Mori > Acked-by: Crt Mori Applied. Thanks, Jonathan > > Best regards, > Crt >

[PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration

Add support for enumerating frame sizes and frame intervals from the first subdev via the V4L2 interfaces. Signed-off-by: Russell King --- drivers/staging/media/imx/imx-media-capture.c | 62 +++ 1 file changed, 62 insertions(+) diff --git

[PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration

Add support for enumerating frame sizes and frame intervals from the first subdev via the V4L2 interfaces. Signed-off-by: Russell King --- drivers/staging/media/imx/imx-media-capture.c | 62 +++ 1 file changed, 62 insertions(+) diff --git

[PATCH 2/4] media: imx: allow bayer pixel formats to be looked up

Allow imx_media_find_format() to look up bayer formats, which is required to support frame size and interval enumeration. Signed-off-by: Russell King --- drivers/staging/media/imx/imx-media-capture.c | 11 ++- drivers/staging/media/imx/imx-media-utils.c |

[PATCH 1/4] media: imx-media-csi: fix v4l2-compliance check

v4l2-compliance was failing with: fail: v4l2-test-formats.cpp(1076): cap->timeperframe.numerator == 0 || cap->timeperframe.denominator == 0 test VIDIOC_G/S_PARM: FAIL Fix this. Signed-off-by: Russell King ---

[PATCH 2/4] media: imx: allow bayer pixel formats to be looked up

Allow imx_media_find_format() to look up bayer formats, which is required to support frame size and interval enumeration. Signed-off-by: Russell King --- drivers/staging/media/imx/imx-media-capture.c | 11 ++- drivers/staging/media/imx/imx-media-utils.c | 6 +++---

[PATCH 1/4] media: imx-media-csi: fix v4l2-compliance check

v4l2-compliance was failing with: fail: v4l2-test-formats.cpp(1076): cap->timeperframe.numerator == 0 || cap->timeperframe.denominator == 0 test VIDIOC_G/S_PARM: FAIL Fix this. Signed-off-by: Russell King --- drivers/staging/media/imx/imx-media-csi.c | 4 +++-

Re: [PATCH v2 01/17] iio: adc: ina2xx: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH v2 01/17] iio: adc: ina2xx: Add OF device ID table

On 15/03/17 04:44, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees. This is working on the assumption that a > I2C device registered via OF will always match a legacy I2C device ID and > that the MODALIAS

Re: [PATCH] iio: accel: Prefer unsigned int to bare use of unsigned

On 16/03/17 23:35, Miguel Robles wrote: > Fix checkpatch warnings: > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: Miguel Robles Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it.

Re: [PATCH] iio: accel: Prefer unsigned int to bare use of unsigned

On 16/03/17 23:35, Miguel Robles wrote: > Fix checkpatch warnings: > WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: Miguel Robles Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- >

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > However if you can really call fsnotify hooks with 'path' available in all > the places, it should be equally hard to just pass 'path' to > vfs_(create|mkdir|...) and that way we don't have to sprinkle fsnotify > calls into several call

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > However if you can really call fsnotify hooks with 'path' available in all > the places, it should be equally hard to just pass 'path' to > vfs_(create|mkdir|...) and that way we don't have to sprinkle fsnotify > calls into several call

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > Right, imx-media-capture.c (the "standard" v4l2 user interface module) > is not implementing VIDIOC_ENUM_FRAMESIZES. It should, but it can only > return the single frame size that the pipeline has configured (the mbus > format of

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > Right, imx-media-capture.c (the "standard" v4l2 user interface module) > is not implementing VIDIOC_ENUM_FRAMESIZES. It should, but it can only > return the single frame size that the pipeline has configured (the mbus > format of

Re: [PATCH v1 2/7] dt-bindings: iio: rockchip-saradc: add support for rk3328

On 16/03/17 08:28, Heiko Stuebner wrote: > Am Mittwoch, 15. März 2017, 18:03:52 CET schrieb c...@rock-chips.com: >> From: Chen Liang >> >> The rk3328 saradc is the same as rk3399. >> >> Signed-off-by: Chen Liang >> --- >>

Re: [PATCH v1 2/7] dt-bindings: iio: rockchip-saradc: add support for rk3328

On 16/03/17 08:28, Heiko Stuebner wrote: > Am Mittwoch, 15. März 2017, 18:03:52 CET schrieb c...@rock-chips.com: >> From: Chen Liang >> >> The rk3328 saradc is the same as rk3399. >> >> Signed-off-by: Chen Liang >> --- >> Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt | 1 + >> 1

Re: [Outreachy kernel] Re: [PATCH] staging: iio: ade7753: replace mlock with driver private lock

On 17/03/17 09:32, Gargi Sharma wrote: > On Mon, Mar 13, 2017 at 5:30 PM, Lars-Peter Clausen wrote: >> >> On 03/12/2017 02:32 PM, simran singhal wrote: >>> The IIO subsystem is redefining iio_dev->mlock to be used by >>> the IIO core only for protecting device operating mode

Re: [Outreachy kernel] Re: [PATCH] staging: iio: ade7753: replace mlock with driver private lock

On 17/03/17 09:32, Gargi Sharma wrote: > On Mon, Mar 13, 2017 at 5:30 PM, Lars-Peter Clausen wrote: >> >> On 03/12/2017 02:32 PM, simran singhal wrote: >>> The IIO subsystem is redefining iio_dev->mlock to be used by >>> the IIO core only for protecting device operating mode changes. >>> ie.

Re: [PATCH v4] staging: Use buf_lock instead of mlock and Refactor code

On Sun, Mar 19, 2017 at 3:45 PM, Jonathan Cameron wrote: > On 18/03/17 18:44, simran singhal wrote: >> The IIO subsystem is redefining iio_dev->mlock to be used by >> the IIO core only for protecting device operating mode changes. >> ie. Changes between INDIO_DIRECT_MODE,

Re: [PATCH v4] staging: Use buf_lock instead of mlock and Refactor code

On Sun, Mar 19, 2017 at 3:45 PM, Jonathan Cameron wrote: > On 18/03/17 18:44, simran singhal wrote: >> The IIO subsystem is redefining iio_dev->mlock to be used by >> the IIO core only for protecting device operating mode changes. >> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. >>

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > Besause fanotify requires `struct path`, the event cannot be generated > > directly in `fsnotify_move` and friends because they only get the inode > > (and their

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > Besause fanotify requires `struct path`, the event cannot be generated > > directly in `fsnotify_move` and friends because they only get the inode > > (and their callers, `vfs_rename`

Re: [PATCH v4] staging: Use buf_lock instead of mlock and Refactor code

On 18/03/17 18:44, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used to protect hardware

Re: [PATCH v4] staging: Use buf_lock instead of mlock and Refactor code

On 18/03/17 18:44, simran singhal wrote: > The IIO subsystem is redefining iio_dev->mlock to be used by > the IIO core only for protecting device operating mode changes. > ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes. > > In this driver, mlock was being used to protect hardware

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

On 18/03/17 18:46, SIMRAN SINGHAL wrote: > On Sat, Mar 18, 2017 at 11:51 PM, Jonathan Cameron wrote: >> On 18/03/17 17:34, SIMRAN SINGHAL wrote: >>> On Thu, Mar 16, 2017 at 3:23 AM, Jonathan Cameron wrote: On 13/03/17 19:53, Alison Schofield wrote: >

Re: [Outreachy kernel] [PATCH v2] staging: iio: ade7753: replace mlock with driver private lock

On 18/03/17 18:46, SIMRAN SINGHAL wrote: > On Sat, Mar 18, 2017 at 11:51 PM, Jonathan Cameron wrote: >> On 18/03/17 17:34, SIMRAN SINGHAL wrote: >>> On Thu, Mar 16, 2017 at 3:23 AM, Jonathan Cameron wrote: On 13/03/17 19:53, Alison Schofield wrote: > On Mon, Mar 13, 2017 at 10:01:07PM

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote: > Along with the norm fallback, GStreamer could could also consider the > currently set framerate as returned by VIDIOC_G_PARM. At the same time, > implementing that enumeration shall be straightforward, and will make a > large

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote: > Along with the norm fallback, GStreamer could could also consider the > currently set framerate as returned by VIDIOC_G_PARM. At the same time, > implementing that enumeration shall be straightforward, and will make a > large

Re: [PATCH v2 2/4] cdc-acm: fix possible invalid access when processing notification

On 3/18/2017 9:52 PM, Tobias Herzog wrote: Notifications may only be 8 bytes so long. Accessing the 9th and s/so//. "So long and thanks for all the fish!" :-) 10th byte of unimplemented/unknown notifications may be insecure. Also check the length of known notifications before

Re: [PATCH v2 2/4] cdc-acm: fix possible invalid access when processing notification

On 3/18/2017 9:52 PM, Tobias Herzog wrote: Notifications may only be 8 bytes so long. Accessing the 9th and s/so//. "So long and thanks for all the fish!" :-) 10th byte of unimplemented/unknown notifications may be insecure. Also check the length of known notifications before

Re: [coreboot] checkpatch: Question regarding asmlinkage and storage class

Dear Joe, Am Sonntag, den 19.03.2017, 01:31 -0700 schrieb Joe Perches: > On Sat, 2017-03-18 at 13:15 +0100, Paul Menzel wrote: > > Dear checkpatch developers, > > > > > > The coreboot project started using checkpatch.pl, and now some effort > > is going into fixing issues pointed out by

Re: [coreboot] checkpatch: Question regarding asmlinkage and storage class

Dear Joe, Am Sonntag, den 19.03.2017, 01:31 -0700 schrieb Joe Perches: > On Sat, 2017-03-18 at 13:15 +0100, Paul Menzel wrote: > > Dear checkpatch developers, > > > > > > The coreboot project started using checkpatch.pl, and now some effort > > is going into fixing issues pointed out by

Re: outreachy/moving a driver out of staging

On Sun, Mar 19, 2017 at 12:37:47AM -0700, Michael Zoran wrote: > I just noticed this e-mail. What exactly is the requirement to get a > driver or subsystem out of staging? This is why each driver in staging is supposed to have a TODO file listing each point that needs to be addressed, and when

Re: outreachy/moving a driver out of staging

On Sun, Mar 19, 2017 at 12:37:47AM -0700, Michael Zoran wrote: > I just noticed this e-mail. What exactly is the requirement to get a > driver or subsystem out of staging? This is why each driver in staging is supposed to have a TODO file listing each point that needs to be addressed, and when

Re: checkpatch: Question regarding asmlinkage and storage class

On Sat, 2017-03-18 at 13:15 +0100, Paul Menzel wrote: > Dear checkpatch developers, > > > The coreboot project started using checkpatch.pl, and now some effort > is going into fixing issues pointed out by `checkpatch.pl`. > > The file `src/arch/x86/acpi_s3.c` in coreboot contains the code

Re: checkpatch: Question regarding asmlinkage and storage class

On Sat, 2017-03-18 at 13:15 +0100, Paul Menzel wrote: > Dear checkpatch developers, > > > The coreboot project started using checkpatch.pl, and now some effort > is going into fixing issues pointed out by `checkpatch.pl`. > > The file `src/arch/x86/acpi_s3.c` in coreboot contains the code

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

"Kirill A. Shutemov" writes: > On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote: >> "Kirill A. Shutemov" writes: >> >> > On x86, 5-level paging enables 56-bit userspace virtual address space. >> > Not all user space is

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

"Kirill A. Shutemov" writes: > On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote: >> "Kirill A. Shutemov" writes: >> >> > On x86, 5-level paging enables 56-bit userspace virtual address space. >> > Not all user space is ready to handle wide addresses. It's known that >> > at

Re: Still OOM problems with 4.9er/4.10er kernels

On 17.03.2017 21:08, Gerhard Wiesinger wrote: On 17.03.2017 18:13, Michal Hocko wrote: On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote: [...] 4.11.0-0.rc2.git4.1.fc27.x86_64 There are also lockups after some runtime hours to 1 day: Message from syslogd@myserver Mar 19 08:22:33 ...

Re: Still OOM problems with 4.9er/4.10er kernels

On 17.03.2017 21:08, Gerhard Wiesinger wrote: On 17.03.2017 18:13, Michal Hocko wrote: On Fri 17-03-17 17:37:48, Gerhard Wiesinger wrote: [...] 4.11.0-0.rc2.git4.1.fc27.x86_64 There are also lockups after some runtime hours to 1 day: Message from syslogd@myserver Mar 19 08:22:33 ...

[GIT PULL] Please pull powerpc/linux.git powerpc-4.11-5 tag

Hi Linus, Please pull a couple of minor powerpc fixes for 4.11: The following changes since commit fb5fe0fd626c425ed41842c4318aa7ab6f3c2db7: Merge tag 'powerpc-4.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2017-03-13 19:48:22 -0700) are available in the git

[GIT PULL] Please pull powerpc/linux.git powerpc-4.11-5 tag

Hi Linus, Please pull a couple of minor powerpc fixes for 4.11: The following changes since commit fb5fe0fd626c425ed41842c4318aa7ab6f3c2db7: Merge tag 'powerpc-4.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2017-03-13 19:48:22 -0700) are available in the git

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Castano Giovanni

Re: Passionate Partner

Dear Sir, Did you recieved my mail? I have sent it twice without a response. Castano Giovanni

Re: outreachy/moving a driver out of staging

On Thu, 2017-03-09 at 22:20 +0100, Greg KH wrote: > On Thu, Mar 09, 2017 at 01:56:49PM -0700, Stephen Warren wrote: > > On 03/09/2017 01:51 PM, Scott Branden wrote: > > > Hi Julia, > > > > > > On 17-03-09 12:36 PM, Julia Lawall wrote: > > > > Hello, > > > > > > > > I discussed the issue of

Re: outreachy/moving a driver out of staging

On Thu, 2017-03-09 at 22:20 +0100, Greg KH wrote: > On Thu, Mar 09, 2017 at 01:56:49PM -0700, Stephen Warren wrote: > > On 03/09/2017 01:51 PM, Scott Branden wrote: > > > Hi Julia, > > > > > > On 17-03-09 12:36 PM, Julia Lawall wrote: > > > > Hello, > > > > > > > > I discussed the issue of

[PATCH 1/2] staging: speakup: Moved AND operator to previous line.

Moved logical AND operator to previous line to fix the following checkpatch issue: CHECK: Logical continuations should be on the previous line. Signed-off-by: Arushi Singhal --- drivers/staging/speakup/main.c | 8 1 file changed, 4 insertions(+), 4

[PATCH 1/2] staging: speakup: Moved AND operator to previous line.

Moved logical AND operator to previous line to fix the following checkpatch issue: CHECK: Logical continuations should be on the previous line. Signed-off-by: Arushi Singhal --- drivers/staging/speakup/main.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 2/2] staging: speakup: spaces preferred around operator

Fixed the checkpatch.pl issues like: CHECK: spaces preferred around that '&' (ctx:VxV) CHECK: spaces preferred around that '|' (ctx:VxV) CHECK: spaces preferred around that '-' (ctx:VxV) CHECK: spaces preferred around that '+' (ctx:VxV) etc. Signed-off-by: Arushi Singhal

[PATCH 0/2] staging:speakup: Multiple checkpatch issues.

Improve readability by fixing multiple checkpatch.pl issues in speakup driver. Arushi Singhal (2): staging: speakup: Moved AND operator to previous line. staging: speakup: spaces preferred around operator drivers/staging/speakup/main.c | 8

[PATCH 2/2] staging: speakup: spaces preferred around operator

Fixed the checkpatch.pl issues like: CHECK: spaces preferred around that '&' (ctx:VxV) CHECK: spaces preferred around that '|' (ctx:VxV) CHECK: spaces preferred around that '-' (ctx:VxV) CHECK: spaces preferred around that '+' (ctx:VxV) etc. Signed-off-by: Arushi Singhal ---

[PATCH 0/2] staging:speakup: Multiple checkpatch issues.

Improve readability by fixing multiple checkpatch.pl issues in speakup driver. Arushi Singhal (2): staging: speakup: Moved AND operator to previous line. staging: speakup: spaces preferred around operator drivers/staging/speakup/main.c | 8

[PATCH] arm64: add dump_stack to show_regs

Recently I found that when the system trigger a soft lockup in interrupt, there is only showing the regs, but no stack trace, it is very difficult to locate the problem: === [10072.999437] NMI watchdog: BUG: soft lockup - CPU#16 stuck for 23s!

[PATCH] arm64: add dump_stack to show_regs

Recently I found that when the system trigger a soft lockup in interrupt, there is only showing the regs, but no stack trace, it is very difficult to locate the problem: === [10072.999437] NMI watchdog: BUG: soft lockup - CPU#16 stuck for 23s!

<    1   2   3   4   5   6